Escolar Documentos
Profissional Documentos
Cultura Documentos
Curso Gestao de Projetos PDF
Curso Gestao de Projetos PDF
Curso
Gestão de Projetos
Carga horária: 60hs
1
Dicas importantes
2
Conteúdo
Introdução
Evolução do Gerenciamento de Projetos
O Trabalho nas Organizações
Origem dos Projetos
Metodologia de Gerenciamento de Projetos
Conceituações
Organização do Gerenciamento de Projetos
Desenvolvimento de Projetos: Idealização e Concepção
Desenvolvimento de Projetos: Planejamento
Cronograma de Execução
Orçamento de Custos
Plano da Qualidade
Plano de Comunicação
Plano de Suprimentos ou Plano de Aquisições
Execução e Controle
Gerenciamento de Escopo
Gerenciamento de Riscos
Gerenciamento de Stakeholders
Administrando Conflitos em Projetos, via Gerenciamento de Stakeholders
Encerramento do Projeto
Bibliografia/Links Recomendados
3
Introdução
Legenda:
SF – Sr. Fortunato
PMI – Sr. Paulo Martins Inácio
MC – Maria Conselheira
DS – Delma da Silva
PR – Pedro Rocha
SB – Sr. Been
Prezado Colaborador:
4
Com o objetivo de informar adequadamente
sobre a importância das boas práticas em
gerenciamento de projetos e os benefícios de
sua utilização, convidamos a participar do “I
Encontro de Gerenciamento de Projetos”, a
ser realizado hoje, conforme programação:
Programação
Apresentação do Presidente: Sr. Fortunato
Evolução do Gerenciamento de Projetos: Sr.
Paulo Martins Inácio
Local
Auditório Térreo da empresa
5
Auditório da Empresa
6
Espero que este nosso encontro seja interativo e, para isso,
façam perguntas sempre que necessitarem de alguma
informação adicional ou tiverem dúvidas.
7
Estratégicas, que são Programas e Projetos definidos como
prioritários para o alcance dos resultados pretendidos.
8
DS: Você poderia nos explicar melhor por que gerenciar
projetos?
PMI: Claro! Por que gerenciar projetos?
Estudos realizados comprovam que empresas que investiram em
esforços nas fases de pré-desenvolvimento conseguiram no
mínimo duplicar as chances de sucesso no lançamento de seus
produtos.
Evolução do Gerenciamento de
Projetos
9
MC: Sr. PMI, poderia nos dar uma linha de tempo sobre a
utilização do gerenciamento de projetos?
PMI: Vou contextualizar a evolução do Gerenciamento de
Projetos.
Achamos que gerenciamento de projetos é recente ou que está
na moda. Na verdade, a ciência do gerenciamento de projetos
surgiu no início da década de 60, nas universidades americanas,
que constataram a precariedade como eram tocados os projetos.
10
enormes, de difícil operação, confeccionados por pessoas com
pouco conhecimento dos negócios das
empresas.
Tradicionalmente os projetos eram executados considerando
apenas prazo, custos e qualidade. A partir da década de 70, o
quesito escopo passou a ser essencial no processo.
11
gerenciar pessoas, compras e riscos, comunicar, entregar com
qualidade e principalmente ter todos eles integrados.
PMI: Isso mesmo.
SB: Ufa! É muita coisa para um projeto só.
Risos
12
DS: Posso dizer, então, que a nossa área de compras têm
processos e que a implantação de um software de compras é um
projeto?
PMI: Exatamente. Na maioria das empresas, temos
processos/rotinas de compras, onde métodos já foram definidos e
implantados. Essas áreas atendem a vários setores de forma
sempre contínua.
Já a implantação de um software, independente de ser de
compras, é algo novo, que deve ser tratado como um projeto.
Origem dos Projetos
DS: Mas qual a origem dos projetos?
PMI: Normalmente são elaborados partindo de um problema ou
oportunidade. Como dito anteriormente, são fatos e dados que
foram identificados e apontados no planejamento estratégico da
empresa.
Diversos tipos de projetos ocorrem dentro da organização. Eles
são elaborados partindo de:
13
MC: Como podemos classificar os projetos?
PMI: As categorias mais conhecidas de projetos são:
• Administração;
• Pesquisa e Desenvolvimento;
• Design;
• Construção;
• Manutenção;
• Informática;
• Desenvolvimento de Novos Produtos;
• Eventos;
• Instalação de Equipamentos;
• Melhorias.
14
PMI: Perfeitamente. Iremos para um pequeno intervalo do café e
retornaremos com a descrição geral de alguns itens importantes
para o gerenciamento de projetos.
CATEGORIAS DE PROJETOS
ADMINISTRAÇÃO
PESQUISA E DESENVOLVIMENTO
DESIGN
15
um novo produto ou de um software, etc. Portanto eles vão
somente até a geração da documentação técnica, da construção
de um protótipo, de uma fábrica-piloto, de um modelo em escala,
etc.
Geralmente são precedidos por um projeto do tipo pesquisa e
desenvolvimento. Posteriormente ao seu término, durante a
execução definitiva, o projeto de design é seguido por um projeto
de construção, montagem, programação, etc. Assim, as
finalidades de um projeto de Design são:
• Especificações detalhadas do produto.
• Instruções sobre montagem e construção.
• Testes em protótipos, fábrica-piloto, modelo em escala.
Alguns exemplos:
• Estudo arquitetônico para uma residência (no Brasil, é comum
chamar o produto final desse estudo de “Projeto Arquitetônico”, o
que cria uma certa confusão);
• Estudo hidráulico para um prédio;
• Estudo elétrico para uma fábrica;
• Montagem de uma fábrica-piloto de uma indústria química, para
testes.
CONSTRUÇÃO
MANUTENÇÃO
INFORMÁTICA
EVENTOS
INSTALAÇÃO DE EQUIPAMENTOS
MELHORIAS
18
• Diminuição de perdas de peças que se quebram em uma linha
de produção.
Conceituações
19
SB:Aí é que mora o perigo!!!
Risos de todos
MC: Como disse o Sr. PMI, a metodologia de gerenciamento de
projetos traz um conjunto de métodos, técnicas e ferramentas
para nos auxiliar na execução de programas e projetos.
SB: São muitas informações para eu assimilar. Não acredito que
isso vai dar certo.
MC: Temos que estar mais abertos às mudanças. Vejam só,
demos o primeiro passo ao elaborarmos nossa planejamento
estratégico.
PR: Há, mas esse trabalho ficou só no papel.
DS: Você está precisando de óculos, Pedro. Não reparou que, em
todos os andares da empresa, estão os quadros divulgando
nossa identidade organizacional?
PR: Não é que eu não reparei?
MC: E não é só isso. Recebemos material por e-mail. Temos
insumos suficientes para trabalharmos nossos processos,
programas e projetos.
DS: Mas existem muitos conceitos que ainda não estão claros.
MC: Vamos voltar para o auditório, acredito que neste segundo
tempo tudo será esclarecido.
SB: Lá vamos nós de novo.
1º conceito – PMI
20
Estados Unidos, conta hoje com mais de 200.000 filiados
distribuídos em cerca de 140 países. O PMI compartilha seus
padrões técnicos e éticos com a comunidade internacional de
Gerenciamento de Projetos através de organizações sem fins
lucrativos de âmbito regional. São os Capítulos locais do PMI.
Hoje são aproximadamente 300 capítulos.
Com o passar do tempo, o PMI® se tornou, e continua sendo, a
principal associação profissional em Gerenciamento de Projetos.
Os associados e interessados em Gerenciamento de Projetos
têm à sua disposição uma extensa relação de produtos e serviços
oferecidos pelo PMI®. Esses produtos e serviços estão
detalhados no site do PMI®, que vocês podem acessar a
qualquer momento. O site é www.pmi.org. Vou entregar a vocês
também um arquivo (LINK) com o detalhamento desses produtos
e serviços.
2º conceito – PMBOK
21
O PMBOK® Guide também estabelece uma linguagem comum
para a profissão, servindo de referência básica para qualquer um
que se interesse pelo Gerenciamento de Projetos e, como tal,
não deve ser encarado como um documento que contemple a
totalidade do conhecimento de Gerenciamento de Projetos.
Periodicamente são realizadas revisões, e novas versões são
desenvolvidas.
3º conceito – Projetos
MC: O principal conceito de projetos vem do trabalho
desenvolvido pelo PMI?
PMI: Sim. Segundo PMI “Projeto é um esforço temporário
empreendido para criar um produto, serviço ou resultado
exclusivo”.
Temporário, pois cada projeto tem início e fim definidos; e
Exclusivo, pois o produto ou serviço gerado é diferente, em algum
ponto, de qualquer produto ou serviço existente.
22
DS: Mas quais são as principais características de um projeto?
PMI: Um projeto possui várias características, dentre as quais eu
destaco:
• ele é sempre Multifuncional, pois requer recursos de várias
áreas, sejam recursos humanos, materiais ou financeiros;
• envolve incertezas relativas a escopo, prazos e conteúdo de
forma geral, que, no início, são grandes, mas diminuem com seu
andamento;
• podem sofrer Alterações de escopo, custo e prazo durante sua
realização;
PR: Você já classificou os projetos. Poderia me dar exemplos de
projetos?
PMI: É claro! Exemplos de Projetos:
• construção de uma usina siderúrgica;
• desenvolvimento de um software de computador;
• construção de um prédio;
• lançamento de um novo modelo de automóvel;
• implantação de um Sistema da Qualidade;
• implantação de um sistema de medição de nível do aço para
produção de lingotes.
23
diferentes preocupações e expectativas das diversas partes
interessadas.
SB: Em resumo, para gerenciar projetos, temos que ser um super
herói.
risos
MC: Mas gerenciamento de projetos é só isso?
SB: Só isso?!
PMI: Segundo descrição do PMBOK, o gerenciamento de projetos
existe em um contexto mais amplo que inclui o gerenciamento de
programas, o gerenciamento de portfólios e o escritório de
projetos. Normalmente, existe uma hierarquia de plano
estratégico, portfólio, programa, projeto e subprojeto, na qual um
programa constituído de diversos projetos associados contribuirá
para o sucesso de um plano estratégico.
5º conceito – Programas
PR: Tudo muito lindo, mas ainda não sei como isto vai facilitar o
meu trabalho. Vamos acabar misturando “alhos com bugalhos”.
PMI: Como acabei de dizer, o gerenciamento de projetos existe
em um contexto muito mais amplo. Dessa forma temos como
gerenciar projetos, através de programas.
Um Programa é um grupo de projetos relacionados entre si,
administrados e coordenados de forma centralizada para se
obterem benefícios e controles não disponíveis, se administrados
individualmente.
Programas possuem um Ciclo de Vida e projetos podem ser
acrescentados ao longo do ciclo conforme necessidade e
objetivos.
Programas podem incluir elementos de trabalho fora do âmbito
do escopo de seus projetos. Os projetos de um programa podem
ser associados a linhas específicas de um negócio ou a tipos
gerais, como infra-estrutura e melhoria interna de processos.
Programas também envolvem séries repetitivas ou cíclicas de
ações.
Exemplos:
24
• O programa de um novo modelo de carro pode ser dividido em
projetos de desenho técnico e atualização de cada componente
principal (por exemplo, transmissão, motor, interior, exterior),
enquanto a fabricação acontece na linha de montagem;
• Empresas realizam programas de construção anual, uma
operação regular e contínua que envolve muitos projetos.
O gerenciamento de programas compreende a administração
coordenada e centralizada dos projetos que o compõem, visando
a alcançar os objetivos estratégicos e os benefícios do programa.
A estrutura do programa precisa ser revisada e ajustada
periodicamente, em resposta ao desempenho interno e a fatores
externos governamentais, tecnológicos, políticos e econômicos.
Pontos-chave a respeito de programas e projetos:
• executar um programa é como operar um negócio;
• ambos têm os clientes e outros envolvidos com interesse no
resultado;
• ambos têm uma missão contínua, um propósito e uma visão;
• ambos também precisam de estratégias e planos com metas de
longo prazo e objetivos;
• o programa é composto por todos os projetos que, direta e
indiretamente, conduzem ao atendimento de sua meta;
• em gerenciamento de programas, os elementos principais são
planejamento, orçamento, estimativas de recursos, liderança e
coordenação;
• o coordenador de programa deve produzir uma série de planos
específicos e relacionados, que incluem planos estratégicos,
execução, custos, pessoal, comunicação, negócio e tecnologia;
• projetos bem definidos aumentam as chances de sucesso do
programa;
• programas são dinâmicos e requerem revisão periódica e
ajuste.
DS: Nem todos os conceitos estão muito claros para mim. Posso
dizer que gerenciamento de programas é a mesma coisa que
gerenciamento de portfólio?
PMI: Não. Portfólio é mais amplo. Portfólio é o conjunto de
projetos e/ou programas de uma organização, entidade ou
gerente. Os projetos e/ou programas que compõem um portfólio
não são necessariamente dependentes ou diretamente
relacionados.
PR: Agora bagunçou minha cabeça. Então para que utilizamos
gerenciamento de programas, se podemos utilizar o
gerenciamento de portfólios?
PMI: As empresas utilizam o gerenciamento de portfólios quando
já possuem uma estrutura bem consolidada de gerenciamentos
de projetos.
Dessa forma, o gerenciamento de portfólio passa a ser um
processo de decisão dinâmico, através do qual uma lista de
projetos para novos produtos (e para Pesquisa &
Desenvolvimento) é constantemente atualizada e revisada. Neste
processo, novos projetos são avaliados, selecionados e
priorizados; os existentes podem ser acelerados, eliminados ou
"despriorizados"; e recursos são alocados e realocados aos
projetos ativos.
Segundo Ricardo Vargas, Gerenciamento de Portfólio significa
gerir o conjunto dos projetos e programas com um todo sistêmico.
Mas não é um todo indiferenciado. É, sim, um sistema que
comporta diferentes graus de contribuição estratégica. Requer
agrupar e discriminar todas as iniciativas, permitindo:
• a alocação diferenciada dos recursos,
• a alocação adequada dos esforços para atingir os objetivos; e
• a gestão ótima dos investimentos.
DS: Mas que benefícios a empresa tem em utilizar o
Gerenciamento de Portfólios?
PMI: O Gerenciamento de Portfólios está diretamente vinculado às
estratégias da empresa. Se vocês lembrarem o que eu disse
anteriormente, as estratégias traduzem a direção da empresa
para o alcance dos objetivos. Dessa forma temos os seguintes
benefícios:
26
• permite validar a estratégia corporativa;
• permite o gerenciamento de recursos;
• liga os resultados dos projetos com as estratégias
organizacionais;
• mantém a visibilidade de todas as informações vitais dos
projetos;
• facilita o acesso e as comunicações dentro da organização; e
• subsidia a tomada de decisões.
SB: Tenho uma memória visual. Você não teria por acaso uma
representação gráfica de como todas as informações estão
relacionadas?
PMI: Tenho sim. Veja a o próximo slide.
7º conceito – Convênios
28
8º conceito – Contratos
29
PMI: Isso mesmo. Bem pessoal, termino aqui a minha
apresentação. Espero ter contribuído com informações que lhes
permitam aprofundar seus conhecimentos em gerenciamento de
projetos.
SF: Gostaria de agradecer a todos pela participação neste
encontro. Tenho a certeza de que demos o primeiro passo para a
implantação de uma boa gestão de projetos na empresa. O Sr.
Paulo Martins Inácio estará à disposição para quaisquer
esclarecimentos que vocês necessitem tendo em vista o bom
desenvolvimento de suas tarefas. Desejo a vocês um ótimo
trabalho.
Na empresa:
30
DS: Ótima idéia. Toda essa conversa me deixou com fome.
MC: Aonde vamos almoçar?
SB: Tem um restaurante de um amigo meu, que foi inaugurado na
semana passada. Vamos conhecê-lo?
PR: Espero que a comida seja boa!
Rsrs
1º – Ciclo de Vida
31
DS: Você quer dizer que ela foi plantada, cresceu, deu frutos e
agora está morrendo?
MC: Isso mesmo!
PR: Faço minhas as palavras do Been. O que isso tem a ver com
gerenciamento de projetos?
MC: O conceito de ciclo de vida é: “Conjunto de atividades que
caracterizam a seqüência de desenvolvimento do projeto,
organizadas em fases e etapas”. É isso que a Delma descreveu.
A árvore passa por várias fases e etapas, como um projeto.
PR: Você quer dizer, então, que o ciclo de vida de uma árvore é
igual ao ciclo de vida de um projeto? Você ficou maluca!
MC: rsrs. Eu não disse que são iguais, e sim que possuem as
mesmas características, ou seja, um ciclo de vida define o início e
o fim de um projeto.
DS: Se entendi bem, podemos dizer, então, que todos os projetos
possuem um ciclo de vida, ou seja, nascimento, maturidade,
velhice e morte.
2º – Processos
32
MC: Voltando ao início da nossa conversa, observe aquele ninho
que está na árvore. O que você vê?
PR: Um ninho cheio de passarinhos cantando. E daí?
MC: Veja com outros olhos e lembre o que a Delma falou. Tudo
não passa de um ciclo. Os passarinhos nascem, aprendem a
voar, depois acasalam, tem seus filhotes e depois morrem.
As etapas estão ligadas umas nas outras. Os processos do
gerenciamento de projetos também. Podemos dizer que
processos são conjuntos de ações ou atividades
interrelacionadas, para criar um produto ou serviço específico.
33
1. Ciclo de vida é formado por processos;
2. Os processos são: processos de iniciação; processos de
planejamento; processos de execução; processos de
monitoramento e controle; processos de encerramento; e que
3. O inter-relacionamento desses processos permite um bom
gerenciamento de projetos.
MC: Muito bom, Pedro. É exatamente isso.
SB: Então gerenciar projetos é muito fácil!
DS: Fácil eu não diria. Exige conhecimento e dedicação.
SB: Já estou com muita fome. Podemos ir para o restaurante?
DS: Boa idéia. Daqui a pouco não conseguimos nem lugar no
restaurante para almoçar.
PR: Então vamos todos no meu carro. Assim continuamos essa
conversa. Este assunto está começando a me interessar.
4º – Áreas de conhecimento.
34
MC: Tudo!
35
SB: É Delma...tenho que concordar com você. Gerenciar projetos
exige muito conhecimento. Veja o quadro que a Maria nos
mostrou. Até me deu mais fome. Esse quadro parece uma sopa
de letrinhas.
DS: Você leva tudo na brincadeira, mesmo quando o assunto é
sério.
Risos
PR: Chegamos. Vou estacionar enquanto vocês entram.
SB: OK, Rocha. Iremos procurar uma boa mesa e aguardamos
você.
____________________________________________________
_______________________________________
ÁREAS DE CONHECIMENTO
36
Gerenciamento do Tempo – processos que garantem que o projeto
seja concluído no tempo correto. Consiste de definição das
atividades, sequenciamento de atividades, estimativas de
duração de atividades, criação do cronograma e controle do
cronograma.
Gerenciamento de Custo – processos necessários para garantir que
o projeto seja completado dentro do orçamento aprovado.
Consiste de planejamento de recursos, estimativa de custos,
definição de orçamento e controle de custos.
Gerenciamento da Qualidade – processos necessários para que o
projeto satisfaça as necessidades para as quais foi criado.
Consiste do planejamento, asseguramento e controle da
qualidade.
Gerenciamento de Recursos Humanos – processos para garantir o uso
mais eficiente das pessoas envolvidas no projeto. Consiste de
planejamento organizacional, bem como de formação e
desenvolvimento da equipe.
Gerenciamento de Comunicações – processos necessários para que a
informação do projeto seja gerada, coletada, disseminada,
armazenada e/ou descartada da forma correta. Consiste de
planejamento da comunicação, distribuição da informação,
relatórios de desempenho e fechamento administrativo.
Gerenciamento de Risco – processos que identificam, analisam e
respondem aos riscos do projeto. Consiste de identificação de
riscos, quantificação e qualificação de riscos e desenvolvimento e
controle da resposta aos riscos.
Gerenciamento de Aquisições – processos necessários para a
aquisição de bens e serviços de terceiros. Consiste de
planejamento de aquisições, planejamento de solicitações,
seleção dos fornecedores, administração de contratos e
fechamento de contratos.
37
No Restaurante
38
1º - Termo de abertura
39
crítica com vistas a identificar algumas características básicas do
projeto, para verificar se ele estaria de acordo com os objetivos
de seu dono. O desenvolvimento do termo de abertura do projeto
trata da documentação das necessidades de negócios, da
justificativa do projeto, do entendimento atual das necessidades
do cliente e do novo produto, serviço ou resultado que deve
satisfazer esses requisitos.
SB: Oh! Maria, você falou e não disse nada. Continuo não
fazendo nenhuma ligação do gerenciamento de projetos com a
abertura de um restaurante.
MC: Risos.
2º - Identificação do Projeto
MC: Muito dos nossos sonhos ficam só na nossa cabeça, outros
tornam:se grandes idéias e transformam:se em projetos. Acho
que foi o que aconteceu com seu amigo, Been. No caso das
40
empresas, as idéias surgem muitas das vezes da necessidade de
progresso ou de uma oportunidade de mercado.
41
restaurante vai fornecer. É o que acontece com os nomes dos
projetos. Eles identificam o projeto.
PR: Muito fácil. E é só isso. Colocamos o nome do projeto e está
tudo entendido. Até parece.
DS: Não seja tão cético, Rocha. Acredito que todos os processos
venham para facilitar nosso trabalho, desde que muito bem
explicado.
MC: Isso mesmo, Delma. E, no caso do Gerenciamento de
Projetos, temos fatos e dados que comprovam isso. Além do
mais, temos uma metodologia descrita e aprovada em nossa
empresa. Cabe a nós colocá:la em prática.
SB: Para que mexer em time que está ganhando, Maria? Está tão
bem como está!
Todos: Risos
DS: Been, você é muito tranqüilo. Maria, mas identificar um
projeto é só dar nome a ele e pronto?
MC: Além do nome, identificamos quem será o gerente desse
projeto, estabelecemos a justificativa para sua elaboração,
fazemos uma primeira análise crítica de seus custos e benefícios,
além de outros itens, de acordo com o Termo de Abertura que a
empresa estabeleceu em sua metodologia.
PR: Estava fácil demais para ser verdade. Eu não disse que isso
tudo burocratiza nosso trabalho?
DS: Pelo que eu estou percebendo, o termo de abertura pode ser
considerado um resumo do projeto.
MC: Um resumo detalhado. Veja o que mais devemos ter neste
termo de abertura.
SB: Acho que nós hoje só vamos almoçar projeto. Vocês não
querem mudar de assunto?
PR: Quero continuar esta conversa Been, pois temos que
aproveitar o conhecimento da Maria nesse papo descontraído.
DS: Muito bem, Rocha. Concordo com você. É melhor
conversamos e tirarmos nossas dúvidas aqui, do que dentro da
empresa.
SB: Já percebi, sou voto vencido. Já que o que não tem remédio,
remediado está,, então vamos continuar.
MC: Você sempre brincando. Mas, como eu estava dizendo,
quando iniciamos um projeto, precisamos ter algumas
42
informações que são muito importantes para o andamento do
mesmo. Um projeto para uma empresa deve ter uma justificativa,
ou seja, necessitamos identificar qual a oportunidade de mercado
precisamos alcançar ou qual fraqueza interna precisamos
minimizar. Dessa forma, assim que justificamos o porquê do
projeto, estabelecemos o seu objetivo, o prazo para sua
execução e quanto ele vai custar.
PR: De prazo e custo eu entendo bem. Para estabelecermos
prazo e quanto vai custar, não podemos simplesmente colocar no
papel, como um “chute”.
DS e MC: Claro que não!
PR: Então precisamos elaborar um estudo de viabilidade a fim de
definirmos prazo e custo para todos os projetos? Estou
começando a gostar desse assunto.
MC: Depende do tamanho de projeto.
PR: Como é que é?
MC: Desculpe, Rocha. Eu não falei direito. Dependendo do tipo do
projeto, apenas um orçamento inicial é suficiente.
DS: Explique melhor o que são tipos de projeto e sobre custos do
projeto.
MC: OK. Os projetos são muito diversificados, dessa forma existe
a necessidade de que sejam agregados em classes (tipos)
diferenciadas para serem tratados adequadamente, de acordo
com a necessidade de estratégia, gestão, suprimentos,
envolvimento de especialistas, etc.
PR: Mas como são feitos esses agrupamentos?
MC: O Sr. PMI nos apresentou uma lista com esses tipos de
projetos, lembram:se?
SB: Disso eu me lembro. Os projetos podem ser administrativos,
de Pesquisa, de Software, dentre outros.
MC: Muito bem, é isto aí. Dependendo do tipo de projeto, eles vão
apresentar diferentes necessidades. Os projetos apresentam
sempre um grau de incerteza, necessidade de tecnologia,
possuem prazo e têm um custo. Dessa forma um projeto
administrativo normalmente tem um grau de incerteza e custos
baixos, enquanto um projeto de construção tem grau de incerteza
baixa e custos altos. Vejam este quadro:
43
MC: Para propiciar a escolha do nível de gerenciamento,
planejamento e controle, além da documentação a ser utilizada,
classificamos os projetos através do método “valor versus
complexidade”.Os projetos podem variar desde Tipo 1 a Tipo 4,
que significa projetos pequenos, médios, grandes e muito
grandes. Essa variação depende da metodologia adotada por
cada empresa, além do tipo de produto e serviços prestados.
Dependendo da classificação do projeto, maior a necessidade do
detalhamento de custos. Um projeto administrativo tem a
necessidade de um orçamento, enquanto um projeto de um novo
produto necessita de um Estudo de Viabilidade Técnica e
Econômica, mais conhecido como EVTE. Um estudo de EVTE
aconselhará quanto a prazo, equipe, termos de referência e
logística. Informará a natureza e extensão de quaisquer ameaças
ao sucesso do projeto e a extensão e conseqüências do risco.
SB:E aí, Rocha, você bem que poderia nos dar uma aula de
EVTE como a Maria.
44
PR: Aula, eu não sei se sou capaz, mas se vocês quiserem se
aprofundar um pouco sobre esse assunto, tenho um material que
acredito ser de grande ajuda neste novo processo que estamos
trabalhando.
MC: Estou gostando de ver. Você já está começando a se
interessar pelo assunto.
PR: Maria, ainda tenho dúvidas. Como definir o tipo de projeto?
MC: Boa pergunta. Como você gosta muito de matemática, a
definição do tipo de projeto será uma média do grau de
complexidade dos fatores que interferem num projeto.
SB: Como é?!
MC: Calma. Existem fatores que interferem muito, outros pouco e
alguns mais ou menos. Damos peso a essas interferências e
depois fazemos uma média dos valores.
DS: Maria, dê-nos mais exemplos.
MC: Certo. Vamos lá. Vou citar alguns exemplos de complexidade
que usamos atualmente em nossa empresa.
adequação do prazo de entrega: a pressão sobre o tempo é
um dos principais aspectos: quanto maior a pressão, mais complexo
o projeto. Considerar, na avaliação, o dimensionamento da equipe;
45
prioridade sobre os demais, refletindo:se em uma maior
complexidade;
Visibilidade: grau de visibilidade que esse projeto terá em
relação aos parceiros e clientes;
Aderência aos objetivos estratégicos: a quais objetivos
estratégicos da instituição esse projeto visa atender;
nível de interação: grau de interação de empresas associadas
e filiadas a sindicatos envolvidos na execução do projeto. Quanto
menor a integração entre as empresas, maior será a complexidade
do projeto (esse nível deve ser inferido pelo coordenador do projeto,
baseando:se em seu conhecimento do relacionamento entre as
empresas);
46
SB: Nossa! Agora deu um nó na minha cabeça.
DS: Se eu estou entendendo bem, esta matriz nos dará a
dimensão do projeto?
MC: Mais ou menos. Na realidade, a dimensão de um projeto será
determinada confrontando:se, em uma matriz, o valor do
investimento necessário com a sua complexidade.
Existem quatro dimensões possíveis:
47
- Médio: 5 a 8 meses;
- Grande: 9 a 12 meses;
- Muito grande: acima de 12 meses.
Valores financeiros:
- Muito pequeno: R$ 1,00 a R$ 10.000,00;
- Pequeno: R$ 10.001,00 a R$ 50.000,00;
- Médio: R$ 50.001,00 a R$ 250.000,00;
- Grande: R$ 250.001,00 a R$ 1.000.000,00;
- Muito grande: acima de R$ 1.000.000,00.
48
SB: Oh, Maria, os preços deste cardápio podem ser considerados
como sendo o valor do projeto?
MC: Não. Custo é aquilo que o dono do restaurante “pagou” pelos
ingredientes e pela mão-de-obra para confecção dos pratos. Já o
preço é o que eles nos cobra, ou seja, o custo de produção mais
uma margem de lucro.
PR: Maria, nesse caso o valor do projeto é o custo do projeto.
MC: Isso mesmo.
PR: Para calcular o valor do projeto, eu incluo os custos diretos e
indiretos do projeto?
MC: Inclui, sim. Uns dos maiores “estouros” no orçamento do
projeto é justamente o esquecimento na hora de elaborar o
detalhamento dos valores e só incluir os custos diretos.
SB: Puxa, eu fiz uma pergunta tão simples e vocês complicaram
tudo. Alguém pode dizer, então, como é que se calcula o valor de
um projeto?
DS: Pelo que eu entendi o valor do projeto é calculado pela soma
dos custos diretos e indiretos.
MC: Todo projeto tem um orçamento inicial na sua fase de
concepção. Na fase de planejamento, existe o detalhamento dos
custos, o qual chamamos gerenciamento de custos.
SB: Você me apertou sem me abraçar. Cálculo é com o Rocha. E
custo, para mim, é tudo igual. Eu gosto é de escrever. Tudo muito
tranqüilo.
Risos
PR: Acho que posso ajuda:lo, Been. Custos diretos são facilmente
identificados e quantificados a partir dos recursos necessários
para a realização das atividades. Eles são diretamente atribuídos
ao processo e não necessitam de rateio. Por exemplo, no caso
desta refeição, as carnes, os legumes, o tempo da cozinheira são
custos diretos. Custos indiretos são despesas gerais e gastos
incorridos pela empresa em benefício de mais de um processo.
Normalmente são custos relativos à manutenção do negócio.
Aqui no restaurante, a mão-de-obra dos garçons representa
custos indiretos.
SB: Puxa, Rocha, você já está até gostando de projetos!
PR: Estou passando a acreditar que gerenciamento de projetos
não é algo tão complicado.
MC: E não é. Como eu disse antes, temos que estudar, entender
do assunto, conhecer a metodologia adotada pela nossa empresa
e colocá:la em prática. Os benefícios aparecem com o tempo.
49
DS: Isso é verdade. Maria, o Rocha nos deu conceitos de custos
específicos. Eles são os mesmos para os projetos?
MC: São. Explicando com uma linguagem mais de projetos, os
custos diretos normalmente são horas de trabalho, custos de
viagens da equipe, custos dos materiais utilizados no projeto,
dentre outros e os custos indiretos são despesas administrativas
(salários de técnicos e administrativos; energia elétrica, telefone),
despesas com tributos e impostos, etc.
4º - Escopo Preliminar
50
SB: Peguei. E daí?
MC: Observe como ele está distribuído. Você pode descrevê-lo?
SB: Entradas, Prato Principal e Sobremesas.
MC: Podemos descrever esses itens como sendo as metas do
projeto, ou seja, eles têm um objetivo (nesse caso atender
nossos desejos alimentares), tem um preço e um prazo para
ficarem prontos. Em contrapartida, para cada item deste
cardápio, existe uma lista de atividades que devem ser seguidas
para entrega, a qual podemos descrever como escopo.
DS: Gostei dessa comparação. Nunca imaginaria fazer essa
correlação.
PR: Se eu entendi bem, escopo é tudo aquilo que precisamos
fazer para que o projeto “aconteça”.
MC: Isso mesmo. Mas devemos lembrar que, na concepção de
um projeto, o escopo é preliminar, pois, no detalhamento do
planejamento do projeto, podemos ampliar ou diminuir o escopo
inicialmente definido.
DS: Maria, considerando nossa empresa, que presta serviços
para o governo e que está sujeita a algumas regras do governo,
51
como por exemplo, a Lei 8.666 e a Instrução Normativa IN:97,
que impacto isso tem no escopo de um projeto?
MC: No escopo, nada. Esse tipo de “regra” é chamado de
restrição. Normalmente é um evento ou limitação que impacta o
projeto e que deve ser contornado. Uma restrição pode causar
um risco no cronograma, mas a restrição em si não é um risco.
As restrições são fatores que limitam as opções da equipe de
gerenciamento de projetos e que as obrigam a trabalhar de
maneira criativa.
Exemplos de restrições:
Um recurso pode não estar disponível até 30 dias após o início
do projeto.
Tecnologia: usar apenas tecnologias em uso na empresa.
Recursos: não serão contratados terceiros.
Orçamento: custo restrito.
Data: a inauguração da obra está marcada.
52
5º - Identificação de riscos
53
cedo identificarmos os riscos na concepção de um projeto, mais
fácil será gerenciá-los.
PR: Você poderia falar mais sobre a natureza dos riscos?
MC: Rocha, os riscos podem ser de natureza interna e externa.
No caso de riscos externos, não temos controle e tampouco
conseguimos mudar. No caso de riscos internos, dependendo do
risco, podemos controlá-lo e até influenciá-lo. Mas vamos
conversar sobre isso mais tarde. Estou ficando com fome. Vamos
comer um pouquinho?
6º - Stakeholders
54
MC: Também. Stakeholders são pessoas, órgãos, entidades ou
empresas interessadas nos resultados do projeto. Podem estar
diretamente envolvidos com o Projeto ou podem ter seus
interesses afetados positiva ou negativamente em decorrência da
execução ou conclusão do Projeto. Os Stakeholders podem
influenciar o Projeto, bem como os seus resultados.
PR: Então somos “Stakeholders Clientes?”
MC: E também usuários finais.
SB: Quais são os principais stakeholders?
DS: Muito bem, Been, você já está começando a se interessar
pelo assunto. Acho que essa resposta eu sei. Principais
Stakeholders são: Sponsor (que é que paga pelo projeto), o
Gerente de Projeto, os clientes (indivíduo ou organização que
adquiriu os produtos gerados pelo projeto), a Organização
“executora” (entidade responsável pela execução do projeto), a
equipe do projeto, os Fornecedores e os usuários finais que são
os indivíduos ou organização que farão uso dos produtos.
MC: Isso mesmo. Esta nossa conversa está sendo muita boa.
Acredito que assim a utilização do Gerenciamento de Projetos
será muito prazerosa e nos trará muitos resultados.
DS: Também acho. E vocês, rapazes, o que acham?
PR: Estou começando a entender o assunto e acho que poderei
contribuir neste processo, mas ainda não sei se saberei utilizar
este gerenciamento de projetos.
SB: Sei não. Deixe:me conhecer um pouco mais para eu ver
como posso contribuir e saber como utilizar o gerenciamento de
projetos. Vamos continuar almoçando.
55
No Restaurante
56
do gerenciamento de projetos, temos algumas etapas e
procedimentos que são específicas.
PR: E quais seriam essas fases?
MC: Lembra-se da nossa conversa quando estávamos vindo para
cá?
PR: Sobre as fases do ciclo de vida?
DS: Não só sobre o ciclo de vida, mas também dos processos que
compõem cada fase.
MC: Isso mesmo. Todo projeto tem um ciclo de vida com suas
respectivas fases e processos. Dessa forma temos o que
chamamos “Plano do Projeto”.
PR: Lá vem você novamente com mais informação.
DS: Calma, Rocha. Deixa a Maria explicar.
MC: Risos. Como estava dizendo, um dos maiores benefícios de
uma metodologia de gerenciamento de projetos é ter definido o
conjunto de normas e métodos, técnicas, modelos e ferramentas
para desenvolvimento de projetos. Assim, o Plano do Projeto faz
parte desse conjunto.
DS: Mas como é composto o Plano do Projeto?
MC: Ele é um documento composto basicamente por vários
planos auxiliares e específicos de áreas de conhecimento, que
são:
- o Plano Organizacional;
- o Orçamento de Custo;
- o Plano da Qualidade;
- o Plano de Comunicação;
- o Planejamento de Suprimentos;
- Plano de Resposta aos Riscos;
- e o Cronograma de Execução.
O plano inclui as ações para definir, coordenar e integrar todos os
planos auxiliares de trabalho definidos para o projeto.
DS: Podemos dizer que o plano define como o projeto é
elaborado, monitorado, controlado e encerrado?
MC: Sim. Podemos.
PR: Maria, você poderia nos explicar o que significa cada um
deles?
MC: Posso tentar.
SB: Não seja modesta, Maria. Você tem nos ajudado muito com
seu conhecimento. Estou começando até a me interessar pelo
assunto.
57
DS: Começando Been!? Acredito que esse processo “é um
caminho sem volta”.
SB: Caminho sem volta!? Que papo mais fúnebre é esse, Delma?
DS: Você não leva jeito mesmo. Só estou querendo dizer que
esse processo é muito importante para nós e que, ao
trabalharmos com uma metodologia de Gerenciamento de
Projetos, não temos como voltar para os nossos controles
separados.
SB: Ah bom. Assim está melhor.
PR: Been, deixa a Maria explicar.
MC: Vou tentar explicar o plano de projeto deste restaurante,
aliás, o que imagino que foi. O que vocês acham?
TODOS: Boa idéia.
MC: Been, qual o nome do dono deste restaurante?
SB: Luiz Otávio.
MC: Muito bem, vamos lá. Como eu disse no início do nosso
almoço, o primeiro passo é “idealizar” o projeto, estruturando as
idéias e analisando sua viabilidade. O Luiz Otávio idealizou o
restaurante, montou o projeto analisando as oportunidades e
ameaças, bem como sua viabilidade.
SB: Pelo jeito, o projeto do restaurante foi considerado viável,
caso contrário não estaríamos aqui.
MC: Isso mesmo.
PR: Próximo passo.
1º – Plano Organizacional
MC: O próximo passo é a Elaboração do Plano Organizacional.
DS: Com esse nome, mais parece um plano para montar uma
empresa!
MC: É mais ou menos isto. Na realidade, o “Plano Organizacional”
define a estrutura de organização, gestão e a equipe executora
do projeto. No caso da montagem do restaurante, o Luiz Otávio
teve que contar com uma equipe de engenheiro, arquiteto,
marceneiro, eletricista, mestre de obra, dentre outros.
DS: A julgar pelo ambiente, ele também contou com uma
decoradora no seu Plano Organizacional.
PR: É só isso o Plano Organizacional? Você relaciona as pessoas
das quais você precisa para executar seu projeto?
MC: Quando iniciamos o projeto, já apresentamos, no nosso
Termo de Abertura, quais profissionais de que necessitamos; e,
quando elaboramos o Plano, já colocamos os nomes das
58
pessoas ou empresas que irão executar o projeto bem como a
relação de hierarquia entre elas.
DS: Mas é só isso?
MC: No caso do restaurante sim, pois é uma empresa nova.
Podemos dizer que é o primeiro projeto dessa empresa.
1.1 – Equipe de Projeto
59
1.2 – Capacitação
MC: Isso mesmo, Delma. E, em alguns casos, para execução do
projeto, “profissionais da casa” precisam de treinamentos mais
específicos para a execução de algumas tarefas.
PR: Mas, se precisam de treinamento, não é mais fácil contratar
um profissional que já sabe?
MC: Nem sempre. Pense no seu caso. Você é um expert na área
financeira, mas tem pouco conhecimento no mercado de capitais.
É melhor para a empresa treiná-lo e ter o conhecimento na casa,
do que fazer uma contratação temporária.
PR: Não pensei por esse lado.
MC: Assim, quando a empresa identifica as necessidades de
capacitação da equipe, ela elabora um plano de treinamento.
SB: E essa idéia de mudança, o que significa isso?
60
1.3 – Gestão da Mudança
61
todo o quadro de pessoal. Foram observados os tempos de
transição e conclusão de cada etapa, sem prejudicar o
andamento dos trabalhos e sem “rádio peão” entre os corredores.
PR: Este foi um projeto de sucesso. Olha que eu não considerava
que já tinha participado de um projeto e que fui útil.
DS: Viu como as peças se encaixam quando temos os conceitos
certos?
MC: Isto mesmo. Se você quiser aprofundar seus conhecimentos,
sugiro, ainda, a leitura do texto Gestão das Transições.
Vou desenhar para vocês um modelo de Plano Organizacional.
62
2º – Planejamento de Escopo
63
necessidades de negócios, da justificativa do projeto, do
entendimento atual das necessidades do cliente e do novo
produto, serviço ou resultado que deve satisfazer esses requisitos
– tratar como pensamento dos participantes). Então, trata-se de
um documento essencial para o projeto e para o planejamento do
escopo, em particular nos estágios iniciais do empreendimento,
pois consolida informações-chave para suporte à decisão sob
níveis mais elevados de incerteza que caracterizam o início dos
projetos.
DS: Como a Maria já disse, ele é a formalização do projeto.
MC: Isto mesmo. Continuando. Estrutura Analítica do Projeto
(EAP) é a expressão em português para WBS (Work Breakdown
Structure). Segundo o Guia PMBOK®, ela representa uma
“decomposição hierárquica orientada à entrega do trabalho a ser
executada pela equipe do projeto para atingir os objetivos do
projeto e criar as entregas necessárias”.
SB: E daí?
MC: EAP pode ser definido como:
“um agrupamento de elementos do projeto, orientados a
produtos, que organiza e define o escopo total do trabalho”;
1 uma representação gráfica da hierarquia do projeto;
2 identificação de todoo trabalho a ser executado: trabalho que
não está no WBS não faz parte do Escopo do Projeto;
3a base a partir da qual o projeto é construído;
4 reflexão das pessoas sobre todos os aspectos do projeto.
Além disso, uma EAP construída pode ser reutilizada em outros
projetos.
64
4 Ajuda a prevenir mudanças;
5 Focaliza a experiência da equipe naquilo que precisa ser feito,
implicando um projeto de maior qualidade;
6 Promove uma base para dimensionamento da equipe,
orçamento de custo e prazos;
7 Permite provar as necessidades de pessoal, custo e prazos;
8 Ajuda no comprometimento e desenvolvimento da equipe;
9 Ajuda a equipe focar seu pensamento no projeto;
10 Ajuda os membros da equipe perceber seus papéis.
65
Cronograma de Execução
66
maioria das vezes ele irá consumir um capital que ele não tinha
previsto, comprometendo, também, o seu custo, podendo até
mesmo causar sérias conseqüências mercadológicas para o
produto, ou serviço, do projeto.
SB: Lembro-me de o meu amigo Luiz Otávio dizer que ele
estabeleceu prazo para execução da obra do restaurante de
acordo com o projeto arquitetônico, sem estabelecer nenhuma
folga. No entanto, ao iniciar as obras, ele viu que o prazo não era
suficiente e, para não comprometer todo o cronograma, acabou
contratando mais pessoas. Com isso gastou mais dinheiro.
PR: Este foi um bom exemplo. Maria, como estabelecer um
cronograma?
MC: Lembra-se de que eu acabei de falar da estratificação das
atividades?
PR: Lembro. Mas o que são atividades?
MC: Bem. Atividades são etapas necessárias para se contemplar
um projeto. São executadas em uma seqüência caracterizada
pela natureza do projeto. As atividades podem ocorrer
seqüencialmente, ou simultaneamente.
PR: Está bem e daí? Continuo sem entender!
MC: O projeto vai sendo decomposto até que todas as etapas e
entregas sejam atingidas. Os principais tipos de atividades são:
1 – Atividades Executivas, que são aquelas relacionadas
diretamente com a ação dentro do projeto. Exemplo: embalar
computadores; limpar o terreno; digitar o relatório de compras;
2 – Marcos, que representam um evento, ou condição, que
determina a execução de um grupo de atividades relacionadas
entre si, ou o término de uma fase de projeto.
Servem também para identificar as entregas dos pacotes de
trabalho e não possuem duração. São também chamados de
etapa. Como exemplo de marcos, temos: telhado pronto
(entrega); testes do produto realizados; recebimento da 3ª
parcela.
O terceiro e último tipo são as Atividades-Resumo. São
atividades que englobam outras atividades, denominadas
67
subatividades. Elas representam um conjunto de atividades,
totalizando duração, datas e custos das atividades a elas
pertencentes.
PR: Mas como se desenvolve o cronograma?
MC: O desenvolvimento do cronograma deve ser feito
iterativamente, ou seja, ser elaborado de forma progressiva e
repetida até o momento em que seus resultados sejam confiáveis
e possam atender aos objetivos do projeto.
Assim, neste desenvolvimento, estabelecemos as datas de início
e término das atividades. Esse processo é um dos mais
importantes de toda a fase de planejamento, uma vez que
consolida informações de outras áreas, tais como custo, recursos
humanos e escopo. O nivelamento de recursos é uma das
ferramentas utilizadas.
DS: Mas como estimar a duração das atividades?
MC: Segundo o Guia PMBOK®, estimar a duração das atividades
“é obter avaliações quantitativas do número provável de períodos
de trabalho necessários para a conclusão de uma atividade do
cronograma”.
Para elaboração de um cronograma, é necessário o
desdobramento das atividades, como acabamos de falar na
explicação da EAP. Uma das questões mais ignoradas na
elaboração do cronograma é relativa àquelas datas que estão
“amarradas” a determinadas situações. Por exemplo, para o Luiz
Otávio mobiliar o restaurante, ele precisou aguardar a conclusão
da obra. Ele simplesmente não pode colocar os móveis sem que
antes tudo estivesse pronto.
Outras considerações incluem saber quais os recursos serão
utilizados, sua disponibilidade (calendários) e experiências
vivenciadas em outros projetos similares.
SB: Como estabelecemos a duração das atividades?
MC: Boa pergunta. A duração de uma atividade é o tempo
necessário para que a atividade possa ser realizada. Esse tempo
pode ser estipulado em semanas, dias, horas e minutos,
dependendo do tamanho de cada projeto.
68
Essa etapa tem por objetivo calcular ou determinar, corretamente,
a quantidade de tempo necessária para executar cada atividade
para que, ao ser integrante de um cronograma, possa determinar
a duração do projeto. Ela é conduzida em paralelo à alocação de
recursos nas atividades, uma vez que existe uma dependência
intrínseca entre duração e quantidade de recursos.
DS: Por que as estimativas variam tanto?
MC: Porque desconhecemos quais fatores influenciarão a
duração. Então não é possível saber exatamente quanto tempo
será consumido.
Outro fato importante é que muitas vezes, ao elaborarmos um
cronograma, não envolvemos quem irá executar a tarefa.
DS: Você está dizendo que quem deverá preparar as estimativas
são as pessoas que executam as atividades?
MC: Exatamente. Quem sabe o tempo é quem faz.
PR: Realmente é uma etapa bem difícil.
MC: Apesar de ser “difícil”, o envolvimento da equipe do projeto
desde a concepção é fundamental para o sucesso.
PR: Você falou que os prazos das atividades estão “amarrados”.
Explique um pouco melhor.
MC: Está certo. Acho que empolguei um pouco e acabei pulando
uma explicação fundamental nesta fase.
Quando disse que as atividades estão inter-relacionadas, estava
tentando explicar que temos de estabelecer precedentes para
que atividades interdependentes sejam identificadas e o
cronograma do projeto seja determinado.
DS: Maria, li alguma coisa sobre isso. Veja se entendi
corretamente: Uma atividade que comece ou finalize antes que
outra atividade possa começar é chamada predecessora. Uma
atividade que dependa do início ou do final de outra atividade é
chamada de sucessora.
MC: Isto mesmo.
SB: E como definimos esta “relação de amor é ódio”?
69
DS: Amor e ódio é por sua conta.
RISOS
MC: É necessário estabelecermos alguns parâmetros
importantes. São eles:
Data de início do projeto: é o primeiro dia da primeira
atividade a ser desenvolvida. Normalmente essa data é definida
quando apresentamos a proposta do projeto, ou seja, juntamente
com o objetivo do projeto.
Data de término do Projeto – é o último dia da última atividade
a ser desenvolvida. Normalmente é calculada pelo detalhamento do
plano do projeto.
Início da atividade – é a data e a hora em que a atividade se
inicia. Pode ser um dado fixo do projeto ou calculada em
conseqüência de suas atividades predecessoras.
Término da Atividade – é a data e a hora em que atividade
termina. Normalmente, é calculada a partir da data de início da
atividade e de sua duração.
Calendários – os calendários são utilizados para determinar e
selecionar os dias de trabalho, ou folga, do projeto. Os calendários
também devem ser utilizados para indicar horas específicas de
trabalho para um determinado recurso.
Feriados e Dias Especiais – Devem ser sempre inseridos para
que não ocorram erros no gerenciamento das atividades. Por
exemplo, férias coletivas, feriados municipais, véspera de Natal e
Ano Novo, dentre outros.
DS: E férias dos participantes dos projetos?
MC: Boa lembrança. Um projeto pode ter datas especiais para
diferentes participantes do projeto, de acordo com cronograma de
férias de cada um.
SB: Existe alguma forma visual de montar um cronograma, ou
basta detalhar no papel?
MC: Você pode apenas detalhar no papel, no entanto, temos hoje
o que chamamos de diagrama de Gantt.
SB: Muito prazer, Sr. Gantt, eu sou o Sr. Been.
70
MC: Não brinque! Diagrama de Gantt, ou diagrama de barras, é
hoje a forma mais utilizada para representação gráfica de um
cronograma.
O diagrama utiliza barras horizontais, colocadas dentro de uma
escala de tempo. O comprimento relativo das barras determina a
duração da atividade. As linhas conectando as barras individuais
em um diagrama de Gantt refletem as relações entre as
atividades.
DS: O Diagrama de Gantt já foi desenvolvido em software?
MC: Sim. O Diagrama de Gantt é a visualização-padrão da
maioria dos softwares de gerenciamento de projetos.
PR: O software facilita a elaboração do cronograma!
MC: Facilita não, ajuda e muito. Mas temos de lembrar que temos
uma metodologia, e é ela quem facilita o nosso trabalho. O
software é apenas uma ferramenta que nos auxilia na construção
do cronograma.
Orçamento de Custos
SB: E agora, o que fazemos?
MC: O próximo passo é saber quanto custa o nosso projeto.
PR: Mas isto eu já sei. Fizemos o estudo de viabilidade ou
orçamento inicial.
MC: Vamos voltar ao exemplo deste restaurante. O Luiz Otávio
elaborou o projeto e fez o estudo de viabilidade. Os valores
projetados foram transportados para o plano orçamento do
projeto.
PR: O que fazemos agora então é detalhar os valores iniciais, de
acordo com as necessidades de gasto do projeto?
MC: Segundo Ricardo Vargas, a orçamentação do projeto é o
processo que envolve a alocação das estimativas de custos a
cada item de trabalho, de modo a estabelecer uma linha de base
de custos para medir a performance do projeto. Nesse processo,
o fluxo de caixa do projeto é determinado.
DS: Trocando em miúdos, fizemos uma estimativa inicial de
quanto seria o nosso projeto. Agora iremos detalhar os valores
agregando-os por rubrica e o cronograma de desembolso?
MC: Isso mesmo.
SB: Já falei que números não são a “minha praia”. Vocês podem
me explicar em bom português?
71
MC: Desculpe, Been. Vou explicar melhor. Rubricas são contas,
ou grupo de contas.
Desta forma, ao elaborarmos o orçamento do projeto, iremos
detalhá-lo da seguinte forma:
• Salários, Adicionais e Encargos e Benefícios.
• Infraestrutura
• Materiais de Consumo
• Despesas de Viagens
• Serviços 3º – Pessoa Jurídica
• Comunicação e Marketing
• Serviços 3º – Pessoa Física
• Bolsistas e Estagiários
• Despesas Financeiras
• Impostos, Taxas e Contribuições
• Despesas Operacionais
• Investimentos
SB: O que estão dentro destes grupos e como podemos calcular
esses valores?
72
Been, você sabe quanto tempo durou a obra deste restaurante?
SB: Aproximadamente uns quatro meses, entre o início das obras
e a inauguração.
MC: OK. Então, como exemplo:
Premissas da contratação:
Tempo: 3 meses, 4h/dia, 3 dias/semana
Valor da hora: R$ 120,00 (já incluídos os valores com encargos e
tributos, pois é contratação de terceiros)
Total a ser pago:
R$ 120,00 x 4 x 3 x 4,5 x 3 = R$ 19.440,00
Para compra de equipamentos, temos:
Investimentos (bens duráveis)
74
Projetos, também está sendo. Ainda bem que temos você, assim
a transição fica mais fácil.
DS: Concordo com você.
SB: Quando será que este novo processo vai me interessar?
MC: Acho que, a partir de agora, você vai poder contribuir muito,
Been.
Plano da Qualidade
SB: Oba! O que vem agora?
MC: Qualidade do Projeto!
SB: Esse assunto me interessa.
MC: Não adianta estabelecermos metas se não acompanharmos.
O próximo passo no planejamento de um projeto é o plano de
qualidade.
SB: Significa que iremos trabalhar com indicadores?
MC: Exatamente. O Planejamento da Qualidade do projeto
caracteriza-se pela definição dos indicadores que deverão ser
monitorados, a freqüência e a forma de medição.
SB: O Plano de Qualidade trabalha, então, com Gestão à Vista,
Gráfico de Desempenho?
DS: Puxa, até que enfim alguma coisa lhe chamou a atenção!
SB: Sou muito visual. Números, números e mais números
embaralham a minha vista. Gosto de ver cores.
PR: O conceito de qualidade total é o mesmo para qualidade em
projetos?
MC: O objetivo é o mesmo. O mais importante dessa área é
garantir que o projeto será concluído dentro da qualidade
desejada, com a satisfação das necessidades de todos os
envolvidos.
SB: Acho que posso contribuir.
MC: Vamos lá.
SB: A qualidade envolve inúmeras dimensões. Mas acredito que
duas são fundamentais para o Gerenciamento de Projetos:
• Fazer correto desde o início. Neste caso o planejamento inicial e
fundamental. O gerenciamento da qualidade garante que cada
ação seja desenvolvida corretamente na primeira vez. O
processo de correção é várias vezes mais caro que o processo
de planejamento.
• Satisfação do cliente. Aqui existe a necessidade de garantir que
o produto ou serviço seja transferido para o cliente de maneira
correta.
75
MC: Obrigada pelas informações. É muito importante o
envolvimento de todos no processo de gerenciamento de
projetos. É como venho dizendo o tempo todo: cada um tem uma
“qualidade” que pode contribuir para todo o processo.
DS: Existem indicadores fixos?
MC: Sim. Existem dois tipos de indicadores:
1 Básicos: normalmente estabelecidos na Metodologia de
Gerenciamento de Projetos para custo, prazo, esforço.
2 Específicos: definidos pelo gerente/coordenador e dirigidos aos
produtos, considerando suas características técnicas.
Plano de Comunicação
SB: Alguém quer sobremesa?
MC: Eu quero. Adoro doce.
DS: Saiu no jornal uma reportagem sobre as delícias das
sobremesas ligths elaboradas por este restaurante. Eu também
quero conhecer.
MC: Já que estamos falando de reportagem, vamos falar um
pouco de comunicação?
SB: Comunicação em projetos?
MC: Gerenciamento das comunicações. Nossa próxima etapa.
DS: Há uma frase de David I. Cleland, que diz: “A grande maioria
dos atritos, frustrações e ineficiências em nossas relações com
as outras pessoas é causada pela pobreza nas comunicações”
MC: Segundo o Guia PMBOK®, o gerenciamento das
comunicações subdivide em quatro processos: o Planejamento
das Comunicações, a Distribuição de Informações, os Relatórios
de Desempenho ou Performance e o Gerenciamento das Partes
Interessadas.
76
Ainda, segundo o Guia, “o Planejamento da Comunicação é o
processo onde será determinada a necessidade de informações
de cada parte interessada do projeto, bem como o modo como
essa informação será levada ao mesmo e qual o seu nível do
detalhe”.
SB: Posso dizer, então, que o Plano de Comunicação estabelece
os meios e instrumentos para a comunicação de dados e
informações do projeto, de acordo com as necessidades dos
stakeholders.
DS: E quais seriam esses meios e instrumentos?
MC: Os meios podem ser mediante correspondências (e-mails,
cartas, fax), mídia impressa (encartes, releases, notas e matérias
jornalísticas), mídia eletrônica (intranet, sistema de informação) e
os seguintes relatórios (Progresso, Desempenho, Executivo,
Divulgação e gráficos de gestão a vista). E através de eventos.
Os eventos de comunicação são as reuniões realizadas entre os
envolvidos, como por exemplo: “Kick-off”; Acompanhamento de
progresso; Reunião de encerramento.
PR: Quais os propósitos de um plano de comunicação?
MC: O desenvolvimento de um plano de comunicação eficaz deve
ter em mente atingir os seguintes propósitos:
1 Assegurar que as informações importantes cheguem às partes
corretas nos prazos adequados;
2 Apontar e identificar problemas potenciais, por meio de reportes
de andamento programados e consistentes;
3 Gerar entusiasmo e empolgação com o projeto;
4 Facilitar a tomada de decisão e o controle de mudanças;
5 Oferecer um processo específico para feedback e resolução de
conflitos;
6 Melhorar e facilitar o trabalho em equipe, a cooperação e
colaboração.
78
MC: Primeiro devemos informar o nosso público-alvo, ou seja,
qual stakeholder. Vocês se lembram quais são?
SB: Eu acho que lembro. Eles são:
- o Sponsor;
- o Gerente de Projeto;
- os clientes;
- a Organização “executora”;
- a equipe do projeto;
- os Fornecedores;
- e os usuários finais.
MC: Isto mesmo Been. Devemos planejar as informações sobre o
projeto para cada parte interessada. O próximo item é definir qual
evento, conforme falei há pouco.
DS: Pelo que eu estou vendo, se possível, devemos colocar o
nome dos participantes.
MC: Exatamente. E por fim colocar de quanto em quanto tempo
irá ocorrer ou quando irá ocorrer. É um modelo simples, no
entanto, é muito importante. E mais uma coisa, para cada
metodologia adotada, este modelo muda, dependendo, inclusive,
do tamanho do projeto.
79
MC: Ao pé da letra “levar tempo”, ou seja, o tempo necessário
para aquisição de produtos e serviços. Dessa forma, não
corremos o risco de precisar de algo que não foi comprado ou
contratado.
DS: Significa que um plano de aquisições mal elaborado pode
atrasar o nosso cronograma?
MC: Sem dúvidas. Eu disse mais cedo que temos convênios com
o Governo e, por isso, estamos sujeitos à Lei de Licitações 8.666.
O Plano de Suprimentos tem que considerar esse aspecto.
Segundo o Guia PMBOK®, o gerenciamento das aquisições em
um projeto implica a necessidade de condução de processos de
planejamento (planejar compras e aquisições, bem como planejar
contratações), processos de execução (solicitar respostas de
fornecedores e selecionar fornecedores), processo de
monitoramento e controle (administração de contrato) e processo
de conclusão (encerramento de contrato).
SB: Puxa tudo isto?
MC: Tudo isto! Iremos conversar um pouco mais sobre Plano de
Aquisições quando estiver explicando sobre execução e controle
de projetos. Acredito que os exemplos ficarão mais claros.
SB: Puxa, adorei “adquirir” esta sobremesa. Sem dúvidas, ela
está completando o meu “projeto alimentar” de hoje.
Execução e Controle
80
No Restaurante
81
1º: O que controlar e acompanhar
82
MC: Puxa Been, você explicou muito bem. Vejo que o assunto
está lhe interessando!
DS: Acredito que quanto mais integrado nós estivermos, mais fácil
será a implantação da metodologia de Gerenciamento de
Projetos na nossa área.
83
No caso do restaurante, o Luiz Otávio, como único dono, aprovou
todo o projeto e o marco de cada fase. Por se tratar de uma
pequena empresa, ele também foi o gerente do projeto e, neste
caso, autorizou as ações de cada fase.
DS: Refaço a minha pergunta. Como acontece o
acompanhamento dos projetos?
MC: Depende da metodologia adotada!
SB: Lá vem você de novo com metodologia.
MC: Been, a metodologia nos ajuda muito. Assim, apenas como
exemplo, podemos dizer que o acompanhamento de um projeto
pode ocorrer em três etapas:
84
MC: Também não estou me lembrando. Em todo caso, vou
conceituar. Segundo Ricardo Vargas, Escritório de Projetos, ou
PMO (Project Management Office) é um local central para
conduzir, planejar, organizar, controlar e finalizar as atividades do
projeto. Suas principais funções são:
• orientar e apoiar a organização no desenvolvimento de seus
projetos
• desenvolver e manter atualizada uma metodologia de
gerenciamento de projetos
• integrar e coordenar a gestão de projetos
• fornecer informações estratégicas à Alta Administração,
Stakeholders, Gerentes de Projetos e organização.
SB: Temos um escritório de projetos na empresa?
MC: Está em fase de implantação juntamente com a metodologia.
Voltando à explicação anterior, a terceira etapa é:
2º: Ferramentas
86
descritas por meio de um diagrama parecido com uma espinha
de peixe, sendo utilizado para analisar as causas que produzem
efeitos tanto benéficos quanto maléficos.
O Diagrama de Pareto é a representação gráfica utilizada para
evidenciar os fatores que contribuem para ressaltar a importância
relativa entre vários problemas ou de determinadas situações.
Baseia-se no princípio de Pareto, onde 20% dos fatores
respondem por 80% dos resultados.
Apresenta as seguintes contribuições:
• o diagrama sugere atenção a elementos críticos do processo.
Passa, assim, a noção de prioridade a determinados aspectos. O
diagrama ajuda a identificálos;
• o diagrama permite classificar (em ordem decrescente) os
elementos do processo segundo a importância da contribuição de
cada um para o processo inteiro. Permite, também, organizar
esses elementos em categorias, classes ou grupos;
• o diagrama investe na visualização global do processo,
passando a idéia de que essa visão abrangente é fundamental
para decisões nesse nível, sempre de porte amplo;
• a ferramenta mostrará onde se devem priorizar as ações de
melhorias. O diagrama causa e efeito usará como base de ação
esses dados.
Contudo deve-se dar especial atenção ao fato de que nem
sempre os problemas mais freqüentes são os que apresentam
maiores custos.
E há a Matriz de Responsabilidades, que é “uma estrutura que
relaciona o organograma do projeto com a estrutura analítica do
projeto para ajudar a garantir que cada componente do escopo
de trabalho do projeto seja atribuído a uma pessoa responsável”.
É uma ferramenta gerencial que auxilia o processo de
determinação e visualização das responsabilidades de cada
membro da equipe do projeto.
PR: Eu entendo que, no caso dessa matriz, fica clara a
responsabilidade de cada membro na execução das ações.
MC: Esta é uma das vantagens da matriz.
SB: Quais as outras vantagens?
87
MC: Como disse o Pedro, a matriz possibilita que sejam
evidenciados de forma clara e concisa a responsabilidade, a
autoridade e os canais de comunicação. Além disso:
• ressalta indivíduos e/ou organizações sobrecarregados;
• aponta deficiências de falta de pessoal habilitado ou disponível;
• facilita o julgamento sobre a necessidade de remanejamento do
pessoal;
• facilita a visualização do relacionamento de cada atividade ou
fase do projeto com as equipes ou órgãos responsáveis por
algum tipo de ação no projeto;
• auxilia na negociação com outras organizações.
88
3º: Gerenciamento
DS: Maria, falamos das ferramentas de execução e controle, mas
agora relacione-as com os planos elaborados.
MC: OK, vou tentar. Vamos voltar à nossa conversa de quando
estávamos vindo para o restaurante. A fase de execução e
controle é um ciclo PDCA. Assim temos:
1 - Gerenciamento de Prazo:
Lembrando da obra do Restaurante Bem Viver, podemos simular
o acompanhamento do prazo. Vejam o desenho que eu fiz.
89
2 - Gerenciamento de Custos:
90
O progresso do projeto deve freqüentemente ser comparado com
a sua linha de base.
Os desvios mais significativos devem ser comunicados de acordo
com seu impacto até o nível hierárquico adequado do projeto e,
em caso de desvios significativos, ações corretivas devem ser
identificadas e implementadas.
DS: O que é linha de base?
MC: Linha de base é o conjunto de informações iniciais
aprovadas para o trabalho do projeto, em relação às quais é
comparada a execução do projeto e são medidos os desvios para
o controle do gerenciamento. A linha de base da medição de
desempenho normalmente integra parâmetros de escopo,
cronograma, trabalho e custo, mas também pode incluir
parâmetros técnicos e de qualidade.
PR: Juntamente com gerenciamento de custos, acompanhamos
também o planejamento das aquisições?
MC: Sim, Rocha. Os contratos com os fornecedores têm que ser
administrados, de forma que o progresso do escopo contratado
seja verificado e conciliado com pagamentos e disposições do
contrato.
3 - Gerenciamento de Qualidade:
SB: E o gerenciamento da qualidade, como acontece?
MC: Esta é a sua praia.
SB: Dessa parte eu realmente gosto.
MC: O gerenciamento da qualidade está em todo o processo.
Mas, na prática, a qualidade é implementada através de
atividades ou características típicas de melhoria contínua, como,
por exemplo:
• atividades de garantia da qualidade;
• parâmetros quantificáveis para definir como o sucesso será
medido;
• realização de comitês de projeto, com informações sobre o
andamento do projeto, assegurando a realização de revisões (ou
controles) para manter o projeto alinhado com suas metas;
• aceitação, por parte da alta administração, da necessidade de
realizar ajustes, com base na experiência e recomendações dos
gerentes de projeto.
SB: No meu vasto conhecimento em qualidade...
91
PR: Modesto.
RISOS
SB: Continuando meu raciocínio... apesar de o suporte da alta
administração ser necessário para uma implantação bem
sucedida de processos de gestão da qualidade, toda empresa
precisa de diretrizes e processos para transformar políticas de
qualidade em satisfação do cliente.
DS: E satisfação do cliente é um grande passo para o sucesso
dos projetos.
4 - Gerenciamento de Stakeholders
5 - Gerenciamento de Escopo.
93
um processo para gerenciá-las. A questão da comunicação será
um dos pontos básicos no tratamento do assunto.
Existem vários tipos de mudança (escopo, qualidade, prazo,
custos, etc) que levam em conta dois aspectos fundamentais:
Mudanças necessárias (requeridas): normalmente surgem de
problemas de processos, atrasos de cronograma, questões
técnicas ou falta de recursos para o projeto (humanos ou
financeiros). Essas questões necessitam de uma forte atenção
dos gerentes do projeto e eles precisam reagir a elas com
modificações no plano do projeto, no orçamento, no cronograma,
nas entregas ou em algum outro aspecto dos processos do
projeto;
Mudanças solicitadas: é bastante comum que os requisitos
técnicos ou de negócios se alterem durante a vida de um projeto,
demandando certa flexibilidade dos responsáveis pelo projeto e
pelas partes interessadas. Ainda que nem toda solicitação de
mudança seja (ou deva ser) aceita e implementada, precisa haver
um processo onde possa ser tratada.
5º: Comunicação
94
6º: Falhas em Projetos
Gerenciamento de Escopo
96
No Restaurante
97
Conceitos
RISOS
ESCOPO
98
-> Da esquerda para direita: Como o cliente explicou sua necessidade; Como o
gerente de projeto entendeu; Como a equipe projetou; O que foi executado; A
expectativa dos stakeholders; Como o projeto foi documentado; Como o cliente foi
cobrado; Do que o cliente realmente precisava; Como o projeto foi suportado;
Quais os recursos que foram alocados.
RISOS
99
Considerações
100
Se o sponsor concordar em incluir o trabalho adicional, o
coordenador terá o direito de alterar custo, horas de trabalho e a
duração, para refletir esse trabalho. Essa nova estimativa de
custo, o esforço e a duração agora se transformam na nova meta
aprovada.
O coordenador e a equipe de projeto devem reconhecer quando
essas mudanças são solicitadas. Então elas devem seguir um
processo predefinido de mudança do escopo.
Esse processo fornece as informações apropriadas ao sponsor
para decidir se as modificações devem ser aprovadas com base
no impacto no projeto em termos de custo e cronograma.
Mudança de Escopo
101
SB: Que exemplo?
MC: Acompanhem meu raciocínio. Quando saímos para o almoço,
tínhamos um roteiro pré-definido.
DS: – Você quer dizer que o nosso almoço é um projeto?
MC: Sim. É um evento com início e fim definido (horário do
almoço), além de um resultado exclusivo (almoço dos colegas do
setor). Também pode sofrer alterações (como acabou de
acontecer).
SB: Continuo não entendendo.
MC: Nosso almoço tinha as seguintes atividades:
- sair da empresa às 12 horas;
- pegar o carro;
- seguir pelas avenidas principais até o restaurante Bem Viver;
- chegar ao restaurante;
- pedir o almoço;
- pedir a sobremesa;
- pagar pela refeição;
- voltar ao Carro;
102
- retornar à empresa pelas avenidas principais;
- chegar à empresa às 14 horas.
103
104
Modelo de EAP
105
SB: Você poderia detalhar cada um desses passos?
MC: Vejamos:
1º) Escrever o nome do projeto no primeiro nível (nível 0) da EAP:
106
5º) Acrescentar as entregas (produtos) e subprodutos (entregas
parciais) que as compõem:
107
Os componentes que não estão dentro de uma caixa estão
expressos no nível mais baixo de cada ramo da EAP. Esses
componentes são denominados pacotes de trabalho e devem ser
detalhados no dicionário da EAP.
DS: – O que é dicionário da EAP.
MC: É um documento complementar à EAP. Apresenta uma breve
especificação do pacote de trabalho e seu critério de aceitação.
DS: – Esse dicionário é obrigatório?
MC: O guia PMBOK sugere que todos os pacotes de trabalho
estejam detalhados no dicionário EAP. No meu entendimento,
projetos pequenos não precisam dessa obrigação, desde que o
enquadramento do projeto na metodologia de gerenciamento do
projeto da empresa indique esse documento como opcional.
SB: Maria, quando elaboramos um escopo, fazemos também sua
representação através da EAP. Você nos mostrou um exemplo
disso. Quando fazemos mudança, nossa EAP também muda?
MC: Claro. Deverá ser elaborada uma nova EAP com as
alterações.
PR – Estamos chegando à empresa. Podemos continuar a
conversa depois?
MC: Claro, Rocha.
Gerenciamento de Riscos
108
No Carro
PR: Puxa, como o tempo está mudando. Parece que vai cair uma
chuva daquelas.
SB: Vai mesmo. Tomara que você consiga estacionar o carro no
estacionamento coberto.
PR: Também espero. Faz tanto tempo que não chove, que, pelo
jeito, vai ser chuva de granizo. Vai ser um risco deixar o carro do
lado de fora.
MC: Rocha, que exemplo legal você acabou de dar sobre risco!
PR: Como é que é!?
MC: Continuamos nossa conversa no carro.
1º - Conceitos
109
PR: Sim. Risco em projetos corresponde a um evento ou condição
incerta que, se efetivamente ocorrer, pode implicar efeito positivo
ou negativo nos resultados do projeto.
MC: Isso mesmo. Até agora não havia falado muito de riscos, mas
você me deu um exemplo que podemos explorar para falar um
pouco de riscos.
DS: Outro conceito de risco é a probabilidade de um evento
ocorrer associado ao impacto (conseqüência da ocorrência).
MC: Devemos lembrar que o risco pode ser de natureza interna ou
externa. A chuva representa um risco de natureza externa e não
temos controle sobre ele. No entanto o local aonde iremos
estacionar o carro pode ser considerado um risco. Como é um
risco de natureza interna, temos controle sobre ele.
DS: De acordo com as nossas conversas, podemos dizer que o
risco é composto pelo evento, sua causa e o efeito da ocorrência.
MC: Apenas complementando a sua informação, temos:
• Evento: acontecimento, eventualidade.
• Causa: aquilo ou aquele que ocasiona um acontecimento ou faz
com que algo exista; princípio; origem; motivo, razão, pretexto;
partido.
• Efeito: conseqüência; produto de uma causa, fim, destino,
aplicação.
PR: Se entendi bem, se eu estacionar o carro no estacionamento
descoberto, corro o risco de ter o meu carro amassado, caso a
chuva seja de granizo.
MC: Exatamente. Na medida em que eu explicar um pouco mais
sobre riscos, irei fazendo as comparações. Acredito que assim
ficará mais claro.
DS: OK. Você vai explicar um pouco mais sobre todas as etapas
do gerenciamento de riscos.
MC: Vou.
SB:Viver é um risco.
DS:Viver é assumir risco.
PR: Nossa! Vocês dois estão viajando. Vamos deixar a Maria
explicar.
MC: Hoje em dia, uma das áreas de conhecimento do
gerenciamento de projetos que está sendo mais estudada é a do
Gerenciamento de riscos.
110
O gerenciamento de riscos tem como objetivo maximizar os
resultados de ocorrências positivas e minimizar as conseqüências
de ocorrências negativas. O gerenciamento de riscos é composto
por seis etapas. São elas:
1. Planejar a gerência de risco: determinar qual a abordagem e
planejar as atividades de gerência de risco que serão executadas
para o projeto.
2. Identificar riscos: determinar quais riscos podem afetar o
projeto e documentar as suas características.
3. Analisar riscos qualitativamente: avaliar, determinar e compor
os fatores de impacto e probabilidade, bem como priorizar seus
efeitos nos objetivos do projeto.
4. Analisar riscos quantitativamente: analisar os riscos
priorizados, associando a eles um número que permitirá avaliar,
sobretudo financeiramente, as implicações caso esses riscos
venham a ocorrer.
5. Planejar as respostas aos riscos: desenvolver procedimentos e
técnicas para avaliar oportunidades e reduzir as ameaças aos
objetivos do projeto.
6. Controlar e monitorar riscos: executar planos de respostas e
identificar novos, monitorar riscos residuais e avaliar efeitos no
ciclo de vida do projeto.
SB: Está bem. Mas como identifico riscos, analiso, controlo, etc.?
Isso não é fácil.
MC: Não disse que era. No entanto, como já conversamos
anteriormente, existem formas de identificar riscos.
DS: Então identificar riscos é determinar o evento, a causa e o
efeito.
MC: Isso mesmo. Assim, há uma causa para cada risco e um
efeito se o risco ocorrer. A causa é uma situação que existe e que
estabelece um risco potencial. Em geral, a causa é um fato ou
uma certeza para o projeto. Por outro lado, o efeito é o resultado
provável da ocorrência do risco.
PR: Posso dizer, então, que a causa, neste caso, é o
estacionamento lotado. O resultado disso é que meu carro pode
ou não ficar exposto ao tempo.
MC: Grosso modo, pode sim.
SB: Existe alguma técnica para identificar riscos, ou trabalhamos
no “achômetro”?
MC: Been, em projetos “não achamos” nada.
111
DS: É tudo preto no branco.
3º: Identificação dos riscos
112
113
114
SB: Puxa, que lista comprida. Temos que usar essa lista sempre?
MC: Não, Been. Como eu disse, ela é um check list e nos auxilia
na identificação dos riscos de um projeto.
Continuando. Outra técnica é a Comparação Análoga. Essa
técnica identifica riscos com base na idéia de que nenhum projeto
representa um sistema totalmente novo, independente do quão
complexo ele seja. Para tanto, a técnica prevê a identificação de
projetos similares, cujos dados possam ser utilizados para a
revisão ou para a elaboração dos novos projetos.
A identificação de projetos similares envolve a determinação de
características comuns, por exemplo, tecnologia, funcionalidade,
estratégia de contrato e processo de desenvolvimento.
DS: Mas qual a vantagem dessa técnica?
MC: Na realidade, existem vantagens e desvantagens. Uma
vantagem da comparação análoga é que ela é fácil de ser
utilizada. Como desvantagem, tem-se que sua precisão depende
dos dados históricos, da interpretação desses dados e do nível
de detalhe em que estão descritos.
DS: Significa que, para utilizarmos essa técnica, os projetos
anteriores têm que estar bem documentados?
MC: Isso mesmo. Outra técnica é a análise de premissas. Na
análise de premissas, cada projeto é concebido e desenvolvido
com base em um conjunto de premissas.
Esta é uma técnica que explora as incertezas do projeto pela
existência de premissas que foram assumidas, e que podem não
ser verdadeiras. As premissas imprecisas, inconsistentes ou
incompletas deverão ser identificadas.
115
DS: Relembrando. Premissas são fatores que, para os propósitos
do planejamento, consideram-se como verdadeiros, como reais
ou como mais prováveis, como o exemplo que você deu para o
projeto do restaurante.
117
5º: Fontes de risco
SB: Está tudo muito bem explicado. Mas como identifico um risco?
Existe alguma fonte específica?
MC: Existem fontes de riscos, que é um grupo de características
semelhantes que originam os riscos. Por exemplo, pessoas,
tecnologia, escopo e mercado.
SB: Você poderia explicar um pouco melhor sobre essas fontes
de riscos?
MC: Claro. Hoje as fontes mais comuns são:
• Aquisições: riscos relacionados ao tempo para aquisição de
compras de bens e serviços;
• Cliente: riscos relacionados ao envolvimento do cliente e às
relações entre os clientes;
• Comunicação: riscos de não comunicar bem o andamento do
projeto;
• Complexidade do projeto (Escopo): riscos relacionados ao grau
de dificuldade para o desenvolvimento do projeto;
• Composição da equipe (pessoas): riscos relativos aos aspectos
de montagem da equipe. É importante verificar se equipes
mistas, equipes formadas por pessoas que possuem regime de
trabalho diferenciado (funcionários, subcontratados, estagiários),
podem influenciar o andamento do projeto, pois a diversidade
pode trazer para a equipe de desenvolvimento problemas como
comparações salariais e diferentes níveis de comprometimento
entre os seus membros;
• Equipe do Projeto: riscos relacionados à habilidade dos
técnicos, ao relacionamento da equipe e à motivação para o
trabalho;
118
• Gerência de projetos: riscos relacionados à habilidade do
coordenador e às atividades próprias de gerência de projetos;
• Política organizacional: riscos relativos aos aspectos culturais e
políticos da organização;
• Prazo (Tamanho e duração do projeto): riscos relativos ao
tamanho e à duração (prazo) do projeto. Trata-se de aspectos
significativos para o aumento da complexidade, que requerem
uma análise da influência desses
fatores no risco de prazo do projeto;
• Processo (Qualidade): riscos relacionados ao processo, ou seja,
todos os processos necessários para a produção dos produtos do
projeto com qualidade. Portanto a categoria, ao invés de ser
nomeada Processo de Desenvolvimento, foi generalizada
simplesmente para Processo, a fim de ser mais abrangente;
• Tamanho da equipe: riscos relativos aos aspectos de tamanho
da equipe. É diretamente proporcional à necessidade de
entrosamento da equipe e ao esforço para manutenção da
comunicação entre os seus membros, exigindo maior
coordenação do gerente de projeto, o que torna seu trabalho
mais complexo;
• Tempo de dedicação do coordenador ao projeto: riscos relativos
aos aspectos de performance do projeto. Pode ser afetada pelo
número de projetos pelos quais o coordenador de projeto é
responsável ou o seu tempo de dedicação ao projeto.
119
• Falta de boas práticas da equipe técnica
• Conflitos entre os membros da equipe de desenvolvimento
• Freqüente rotação de pessoal na equipe de projeto
• Equipe de desenvolvimento não familiarizada com as
ferramentas
• Membros da equipe de desenvolvimento não familiarizados com
o negócio do cliente
• Atitudes negativas da equipe de desenvolvimento
• Ausência de perfil especializado na equipe de projeto para
atender aos requisitos do projeto
Relativos a Políticas Organizacionais
• Recursos retirados do projeto por causa de mudanças nas
prioridades organizacionais
• Mudanças na gerência da organização durante o projeto
• Políticas corporativas com efeito negativo no projeto
• Influência política no projeto (externa)
• Ambiente organizacional instável
• Reestruturação organizacional durante o projeto
• Ausência de suporte gerencial de alto nível para o projeto
• Ausência ou perda do comprometimento organizacional com o
projeto
Relativos à Complexidade do Projeto
• Dependência de fornecedores externos
• Muitos fornecedores externos envolvidos com o projeto de
desenvolvimento
• Alto nível de complexidade técnica
• Tarefas altamente complexas a serem automatizadas
• Projeto afetando um grande número de departamentos ou
unidades do cliente
• Grande quantidade de interação com outros sistemas
• Projeto envolvendo o uso de novas tecnologias
• Inadequada transferência de tecnologia para o projeto
• Condições de trabalho inadequadas
Relativos a Processo:
• Padrões, políticas e metodologias de engenharia de software
inadequados
• Métodos e ferramentas de engenharia de software inadequados
• Burocracia excessiva
• Falta de suporte para a resolução de problemas técnicos
• Falta de infra-estrutura para reuso
• Falta de prática de reuso
120
• Repositórios de projeto e controle de configuração inadequados
• Ausência de uma metodologia efetiva de gerência de projetos
Relativos à Gerência de Projetos:
• Planejamento inadequado do prazo
• Planejamento inadequado dos recursos necessários
• Planejamento inadequado do orçamento
• Pressão excessiva de prazo
• Baixa produtividade
• Baixa qualidade dos produtos intermediários e finais
• Ausência de “pessoas com perfil” para liderar o projeto
• Acompanhamento do progresso do projeto insuficiente
• Fraco planejamento de projeto
• Falta de definição dos marcos do projeto
• Ineficiência do gerente do projeto
• Inexperiência do gerente de projeto
• Comunicação ineficiente
Relativos a Requisitos:
• Mudanças contínuas dos objetivos e escopo do projeto
• Requisitos conflitantes
• Mudanças contínuas dos requisitos
• Requisitos não definidos de forma adequada
• Falta de clareza dos requisitos
• Requisitos incorretos
• Deficiência no entendimento dos usuários quanto às limitações
ou capacidades do sistema
SB: Puxa. Será que iremos conseguir tratar esse assunto?
PR: Por que não?
SB: São muitas informações e não me sinto seguro em determinar
quais riscos são mais ou menos impactantes.
DS: Estamos iniciando o processo de gerenciamento de projetos.
Acredito que tudo é uma questão de prática.
MC: Concordo com a Delma. Apenas com o tempo, teremos
conhecimento e maturidade para realizarmos uma gestão de
projetos eficiente e eficaz.
121
6º: Planejamento das respostas
Gerenciamento de Stakeholders
124
No Estacionamento da Empresa
125
assuntos relacionados aos stakeholders, para focá-los e mantê-
los integrados ao projeto.
1.1- Sponsor
128
• definir o escopo do projeto;
• identificar e selecionar os recursos (equipe e recursos
materiais);
• liderar a equipe nas fases do projeto;
• estimar e criar o orçamento;
• identificar e gerenciar todas as questões e riscos do projeto;
• criar e manter o plano do projeto;
• gerenciar todas as mudanças no projeto;
• gerenciar a documentação do projeto;
• realizar a prestação de contas mensal e final do projeto;
• comunicar e manter os relatórios de progresso nas reuniões de
acompanhamento;
• produzir o produto / serviço de acordo com as especificações
técnicas, no prazo e custos orçados e com os recursos
disponíveis na organização;
• recomendar o término do projeto ou solução alternativa caso os
objetivos não possam ser atingidos e as obrigações contratuais
permitam;
• tomar ou forçar as decisões requeridas para assegurar que os
objetivos do projeto sejam atingidos;
• ser o ponto focal de contato do projeto com o cliente e gerentes
funcionais;
• negociar com outras áreas de forma a conseguir recursos para
o projeto, sempre que necessário;
• promover as articulações com os stakeholders internos.
130
MC: Isso mesmo. O gerente de projeto não trabalha sozinho, e a
montagem de sua equipe é fundamental para o sucesso dos
projetos.
PR: Quais os benefícios na montagem de uma equipe?
MC: Eu não diria benefícios e, sim, vantagens. Quando montamos
uma equipe, temos:
1. criatividade na solução de problemas, por meio do enfoque
multidisciplinar;
2. especialização e divisão do trabalho, promovendo economias
de escala e aprendizagem bem como minimizando os custos do
projeto;
3. comprometimento da equipe com o sucesso do projeto, já que
este implica o sucesso pessoal de cada um deles.
DS: Mas montar uma equipe não deve ser uma tarefa fácil.
MC: Realmente não é fácil, pois o gerente precisa administrar uma
equipe heterogênea e multidisciplinar. Alguns autores identificam
cinco fases para a composição de uma equipe de projetos.
1ª fase: formação: nessa fase, os membros da equipe podem não
ter papéis claros e provavelmente não se conhecem ou se
conhecem apenas de cumprimentar. Nessa fase, existe um nível
de desconfiança. É importante que o gerente exerça sua
autoridade formal para orientar a equipe;
2ª fase: conflito: nessa fase, os membros da equipe podem
desafiar a autoridade do líder, já que a existência do grupo tende
a limitar a sua expressão individual. São comuns nessa fase as
lutas de poder, determinando as relações e hierarquia final do
grupo;
3ª fase: normas: nessa fase, as regras de conduta ou normas
determinam papéis e responsabilidades, criando um sentimento
de trabalho de grupo e coesão;
4ª fase: desempenho: o grupo se transforma em equipe, onde cada
um dos membros se dedica a uma tarefa específica, buscando
alcançar os objetivos do projeto; e
5ª fase: encerramento: essa fase é alcançada quando o projeto é
encerrado, causando a dissolução do grupo. O líder deve fazer
um balanço da experiência, debater lições aprendidas, aprender
com os erros e se preparar para o próximo projeto.
131
SB: Beleza. Montamos a equipe, desmontamos a equipe, mas
quais são suas funções?
MC: As funções da equipe do projeto são:
• executar as atividades do cronograma físico;
• subsidiar o gerente com informações do projeto;
• dar suporte ao cliente;
• na figura do relator, gerar e manter a documentação durante o
ciclo de vida do projeto, como e-mails e atas de reuniões;
• executar as decisões requeridas para assegurar que os
objetivos do projeto sejam atingidos.
1.4 - Cliente
132
• Um projeto que envolve uma obra em via pública deve
considerar as necessidades da comunidade que será afetada
pelo barulho e pelos transtornos (mesmo que a obra seja em
benefício da comunidade), ou será alvo de reclamações que
poderão levar a atrasos no cronograma.
• Dentro de uma organização, um projeto pode gerar um
resultado que fortalece algumas áreas em detrimento de outras.
Mesmo que essas áreas não participem do projeto, é importante
entender as relações de poder envolvidas, já que os que serão
afetados negativamente poderão tentar boicotar o projeto.
Ao mesmo tempo, o gerente de projeto deve ter cuidado em não
procurar stakeholders por todos os lados, ou ficará com um
cenário difícil de gerenciar. É necessário um limite lógico para a
identificação de quem afeta ou é afetado pelo projeto.
133
2º - O Gerenciamento
134
dos stakeholders sejam atendidas;
4. mobilizar e envolver os stakeholders no projeto, por meio de:
• alocação de trabalho para os stakeholders;
• utilização dos mesmos como especialistas;
• informações sobre o projeto;
• envolvimento dos stakeholders em mudanças no projeto;
• criação de lições aprendidas através dos mesmos;
5. obter a aceitação formal do projeto pelos stakeholders quando
do encerramento do mesmo;
6. diferenciar necessidades e desejos;
7. fixar metas e objetivos juntamente com os stakeholders. Deve-
se envolver os stakeholders criando um conjunto de metas e
objetivos realistas. Os stakeholders se envolverão mais com
metas e objetivos bem definidos desde o início e ajudarão a
garantir o sucesso, principalmente se as metas e objetivos
apontarem para melhorar o desempenho empresarial;
8. negociar os deliverables (entregas): todos os projetos precisam
de um conjunto claro de deliverables dirigidos para alcançar as
metas e os objetivos do projeto. Estes devem ser comunicados
claramente aos stakeholders, e esforços devem ser feitos para
assegurar que haja uma compreensão clara relativa à qualidade
e composição de cada deliverable.
9. garantir que o gerenciamento da comunicação seja claro com
os stakeholders. Uma vez que o projeto esteja em execução, há
dois grupos das pessoas que precisam ser mantidos informados
sobre o progresso: o time de projeto e os stakeholders. O modo
mais efetivo de comunicar o progresso é por meio de relatórios
de progresso regulares, os quais formam um registro útil do
projeto e podem ser enviados por e-mail a todos os envolvidos ou
colocados em um repositório central disponível a todos.
PR: Maria, explique um pouco o que seria necessidades x
desejos.
MC: OK. Nos casos em que existam divergências entre as
necessidades dos diferentes stakeholders, estas devem ser
solucionadas em favor do cliente do projeto.
Expectativas de stakeholders são mais ambíguas do que
requisitos e podem estar “implícitas” de forma intencional ou não
intencional. As expectativas dos stakeholders devem ser
identificadas, documentadas e gerenciadas ao longo do ciclo de
vida do projeto, da mesma forma que os requisitos.
135
DS: Puxa, apesar do gerenciamento de stakeholders não ser uma
das nove áreas de conhecimento, ela exige do gerente de
projetos o mesmo esforço e dedicação!
MC: Isso é verdade. Mas, mesmo assim, como eu acabei de dizer,
o gerenciamento de stakeholders encontra-se presente em todas
as fases, ou seja, no início do projeto, no seu planejamento, na
execução e no encerramento.
SB: Gostei muito desta nossa conversa. Maria, você não teria
nenhum livro ou texto que pudéssemos ler para ajudar a
complementar esse assunto?
MC: Na realidade, saiu recentemente um artigo sobre
gerenciamento de stakeholders. Tenho uma cópia aqui no meu
computador. Vou encaminhá-la para vocês, pois julgo importante
essa leitura.
Este artigo contempla o que acabamos de conversar. Tenho
certeza de que vocês irão gostar muito. (LEITURA
OBRIGATÓRIA: TEXTO “Administrando Conflitos em Projetos, via
Gerenciamento de Stakeholders”: próxima lição)
PR: Vamos colocar a mão na massa. Temos muito trabalho pela
frente.
SB: Maria, quando iremos conversar sobre a fase de
encerramento do projeto?
MC: Primeiro leiam o texto que indiquei e amanhã retornaremos
com esse assunto.
SB: OK. Vamos ao trabalho.
Abstract
136
Este artigo apresenta o importante papel do gerenciamento dos
stakeholders e seus interesses para o sucesso do projeto. Trata
as diversas habilidades do gerente de projetos no relacionamento
com os stakeholders, como: identificação e conhecimento dos
interesses dos stakeholders; estratégia de comunicação junto aos
envolvidos; desenvolvimento, motivação e apoio ao principal
stakeholder: a equipe; administração dos conflitos de interesse; e
a importância da inteligência emocional associada às habilidades
técnicas do gerente.
Os projetos surgem para atender às necessidades do mercado,
legislação, visão da empresa e são demandados essencialmente
pelo cliente/patrocinador. Este quando fica satisfeito significa uma
combinação vitoriosa, indicando que o produto/serviço foi
entregue no valor e tempo certos e de acordo com as
expectativas. Porém, o cliente é um dos stakeholders dentro dos
vários envolvidos no projeto e, como os demais, requer
relacionamento específico de acordo com seus interesses,
influência e expectativas.
Os stakeholders são os envolvidos que influenciam o projeto (ou
são influenciados por ele) positiva e/ou negativamente de acordo
com seus interesses.
De acordo com dados do Benchmarking em Gerenciamento de
Projetos: RJ, COMPASS (2006), 33% dos erros e problemas em
projetos acontecem por falha de suporte e gerenciamento de
stakeholders. Pode-se atribuir diversas causas a essa falha, são
elas:
• Pouca atenção dedicada ao melhor entendimento dos
envolvidos sobre o projeto durante a análise de viabilidade e
planejamento.
• Desconhecimento dos envolvidos e de seus interesses por parte
do gerente de projeto.
• Por vezes, os gerentes de projetos não possuem habilidades
em comunicação, motivação, negociação, administração de
conflitos e de liderança.
O gerenciamento de stakeholders abrange a identificação,
análise, desenvolvimento de ações, comunicações e interfaces
com cada um dos envolvidos no projeto.
137
O sucesso do projeto depende da participação de suas partes
interessadas e, por isso, é necessário assegurar que suas
expectativas e necessidades sejam conhecidas e consideradas
pelo gerente de projeto.
Os interesses e os objetivos
138
• Quem são os stakeholders-chave?
• Quais são seus objetivos, metas, motivações e interesses?
• Qual o poder de influência de cada um na organização?
• Qual a importância e o impacto de cada um no projeto?
• Quais os papéis e responsabilidades de cada um no projeto?
• Como trabalhar com cada um buscando o sucesso do projeto
(sintonia fina)?
• Quais serão as estratégias adotadas na relação de cada
stakeholders-chave?
139
A matriz de relatórios deve conter as seguintes informações,
conforme tabela 2:
• Relatórios a receber (área de interesse);
• Volume/nível de detalhe;
• Melhor formato;
• Freqüência;
• Mecanismo de entrega.
140
• Receptor: é a pessoa a qual a mensagem é enviada. As
informações são filtradas pelos receptores, por meio do
conhecimento que têm do assunto, influências culturais, idioma
emoções, gestos, etc.
• Mensagem: é a informação enviada e recebida. Ela tem diferentes
tipos: oral, escrita e corporal, longa ou simples, etc.
• Canal: é o meio que será utilizado para transmitir a mensagem.
• Feedback: é o retorno do receptor.
Devido às diversas formas de interpretação das mensagens
enviadas e recebidas, a comunicação bem conduzida é base de
um projeto bem sucedido. A tarefa do gerente de projetos, nesse
contexto, é identificar a forma que os stakeholders codificam e
decodificam as mensagens, para facilitar sue trabalho junto às
diversas formas de apresentação e transmissão a adotar.
A habilidade de comunicar não está só em saber transmitir e
codificar a mensagem corretamente, mas também em saber
ouvir.
A comunicação pode ser formal ou informal, oral ou escrita, ou
até corporal (a comunicação não-verbal compõe mais da metade
da comunicação humana), mas apesar da comunicação oral ser
mais fácil que a escrita, esta é mais adequada para transmitir
mensagens complexas, minuciosas e a muitas pessoas,
permitindo-se revê-las, ficam inesquecíveis.
Administrando os conflitos
141
situações podem inclusive, estimular a busca de soluções
criativas para muitos problemas, proporcionando ganhos tanto
para o projeto quanto para os indivíduos pessoalmente, seja na
forma de crescimento profissional seja na melhoria nos
relacionamentos.
Os conflitos são benéficos quando estabelecem um desafio para
a busca de soluções, motivam grupos a resolver problemas em
conjunto, aumentam o conhecimento após a experiência,
melhoram a iniciativa dos integrantes do grupo e facilitam o
alcance do objetivo comum. Ao contrário, quando uma situação
cria um ambiente de tensão e pressão excessiva, tornando o
trabalho improdutivo, distorce o comportamento dos indivíduos
gerando sensação de perda de confiança e permite
demonstrações de poder desnecessárias, o conflito é prejudicial.
Um dos grandes desafios do gerente do projeto é saber identificar
a existência de conflitos e implementar as técnicas adequadas a
cada caso para resolvê-los da forma mais produtiva para a
equipe e, principalmente, em linha com os objetivos do projeto.
Segundo FERNANDES (2004), “os conflitos possuem várias
origens” e classificamos nos seguintes tipos:
• De ordem pessoal.
• De relacionamento com outros indivíduos.
• De ordem organizacional.
Qualquer pessoa possui condições internas que, em dado
momento, influenciam seu desempenho e suas reações, e podem
fazê-las entrar em choque com seus pares.
Questões de ordem pessoal, psicológicas, de difícil identificação,
são problemas complexos de resolver. Além de prejudicar os
relacionamentos, influenciam também na vida diária da pessoa,
interferindo na capacidade de concentração, no raciocínio, na
motivação e, principalmente, no equilíbrio emocional.
Os conflitos de relacionamento com outros indivíduos ocorrem
por opiniões antagônicas, falhas na comunicação, problemas de
personalidade ou objetivos conflitantes. Todos têm necessidades
diferentes, entretanto, o reconhecimento do trabalho, a
valorização como indivíduo, a auto-estima, o respeito e a
142
segurança são características desejadas por todos e muito
necessárias para a manutenção do equilíbrio.
Preservar valores e evoluir, profissional e pessoalmente, é
determinante para o ser humano. Entretanto, os valores
constituídos através do desenvolvimento pessoal, não adiantam
se, em conjunto a eles, o indivíduo não possuir a capacidade de
aceitar diferenças e encontrar caminhos satisfatórios de
convivência com os outros.
Em complemento ao estado pessoal interno e as características
individuais, muitas vezes a razão dos conflitos está relacionada a
fatores ambientais. Novas diretrizes e políticas organizacionais,
reestruturações, escassez de recursos, choques culturais,
influências políticas, entre outros, são motivos muito encontrados.
Objetivos conflitantes entre grupos, departamentos e pessoas,
sejam de liderança ou não, criam e aumentam situações de
tensão que exigem a adoção de técnicas específicas de
administração de conflitos.
A administração de conflitos permite que uma solução seja
encontrada e implementada, tanto para um simples problema ou
para causas complexas.
De forma geral, o enfoque deve ser sempre o da solução. Atuar
de forma positiva, buscando o equilíbrio no resultado entre as
partes é fundamental para a conservação do estado de confiança
da equipe e manutenção dos objetivos do projeto.
O gerente de projetos é, além de um coordenador, um
negociador que deve ter grande capacidade de comunicação,
uma vez que, boa parte do seu tempo será empregado nessa
tarefa.
Saber identificar características pessoais, comportamentos
situacionais e situações de risco, ajudará a evitar conflitos
iminentes e extinguir os já existentes.
O conhecimento para identificar os tipos de comportamento de
cada um, seja Passivo, Agressivo ou Assertivo, associados aos
tipos de poder, como Coercivo, Recompensador, de Conexão,
Legítimo, de Informação, de Referência ou Especialização e,
dessa forma, encontrar a solução adequada, é parte fundamental
das habilidades do gerente de projetos. Ele deverá julgar qual a
143
melhor alternativa considerando os tipos de comportamento e
poder variados.
Além da capacidade acima descrita, dificilmente um gerente de
projetos poderá desempenhar bem suas funções se não possuir
a capacidade de ser um bom negociador.
Um bom negociador deve conhecer muito bem a realidade de
cada um dos envolvidos, conhecer com profundidade o problema
e estar preparado para enfrentar os desafios para identificar
soluções. Na mesma linha, ter a competência para identificar
soluções.
Na mesma linha, ter a competência para identificar cenários,
possuir conhecimento do assunto e saber se relacionar, são
habilidades que permitirão ao gerente a correta inserção no
contexto do problema. Para identificar os cenários, é necessário
ter a capacidade de interpretar questões de ordem pessoal,
psicológicas, familiares, culturais e econômicas. Conhecer o que
está sendo negociado facilitará a distinção entre o que é bom e o
que não é como alternativa. Em complemento, e como fator
crítico para o êxito na negociação, está o relacionamento
interpessoal.
A fusão entre a habilitação técnica, as competências de
comunicação, negociação e as técnicas de administração de
conflitos, irá proporcionar a identificação das melhores
alternativas e a conclusão das negociações através da adoção da
melhor solução, de forma convincente e satisfatória, apoiada em
argumentos legítimos e coerentes.
144
A formação da equipe de projeto deve considerar as
competências individuais necessárias para o desenvolvimento
das atividades e alcance das metas. Os indivíduos da equipe
devem ser escolhidos com base em sua capacidade reconhecida
de exercer a função necessária, e talvez, e ainda mais
importante, sua capacidade de atuar em conjunto de forma a
potencializar a capacidade individual dos integrantes da equipe.
Com uma equipe entrosada e atuando em sinergia, haverá a
multiplicação das capacidades individuais e a garantia de um
projeto bem-sucedido.
O gerente de projeto exerce um papel fundamental de liderança.
Segundo COUTO (2002), “ele é responsável pelos aspectos da
administração das personalidades e dos egos envolvidos” e, por
isso, deve atentar para os diversos aspectos fundamentais ao
sucesso do projeto:
• Motivação. Um dos pontos cruciais do papel de liderança é a
motivação do time. Somente com uma equipe motivada é que se
completa um objetivo. Pessoas motivadas executam trabalhos de
qualidade e mantêm um compromisso com o resultado. O
gerente de projetos deve possuir a capacidade de percepção
para medir o grau de envolvimento dos integrantes, assim como o
resultado dos seus trabalhos.
O acompanhamento e avaliação da consecução das ações do
projeto de acordo com as responsabilidades específicas de cada
integrante passam necessariamente pela sensibilidade do
gerente em perceber, assimilar e reconhecer o grau de motivação
e de resultados gerados pela equipe.
• Comunicação. Cabe ao líder da equipe estabelecer e gerenciar a
comunicação, de forma clara e transparente. As informações
devem fluir livremente na equipe, que deve se sentir informada e
com um bom canal de comunicação. Manter um bom canal de
comunicação com informações de tudo que acontece e das
modificações porventura realizadas é um feedback esperado no
trabalho de equipe. Cabe no item comunicação, a gestão do
conhecimento do projeto para a formação de quadros
capacitados, incrementando os ativos intangíveis da organização
e facilitando a execução do projeto.
• Ambiente. O ambiente de trabalho é também considerado um
fator decisivo para o sucesso de um projeto. Deve ser percebido
145
pela equipe um ambiente flexível, agradável, criativo e
incentivador das realizações pessoais. A questão do clima
organizacional e conseqüentemente do ambiente de projetos e
fundamental para o aumento da melhoria da qualidade do
trabalho e eficiência das ações-chave do projeto. Quando um
indivíduo se sente mais confortável num ambiente de trabalho,
gasta menos energia na sua defesa e a desvia para o
desempenho de suas atividades tornando-se satisfeito com seu
trabalho e membro ativo de uma equipe.
Criar mecanismos de motivação e desenvolvimento da equipe,
manter um canal de comunicação em ambas as direções, cuidar
do ambiente de trabalho são atitudes que contribuem para a
manutenção de uma equipe engajada no sucesso da empreitada.
Considerações finais
147
desenvolvimento da equipe são requisitos básicos exigidos ao
bom gerente de projetos.
Encerramento do Projeto
No dia seguinte
MC: Bom dia a todos! E aí, gostaram dos textos que eu passei
para vocês?
DS: Como disse o Pedro e pelas nossas conversas, temos muito
trabalho pela frente. Os textos ajudaram muito a clarear algumas
dúvidas.
PR: Para mim, que estava bem receoso, achei a leitura muito
produtiva.
SB: OK. Tenho que admitir. Todo este assunto é muito
interessante. Muita coisa para fazer, mas sem dúvidas irá
contribuir muito para o nosso dia-a-dia. Vamos ao trabalho.
DS: Até que enfim, Been. Você agora percebeu a importância
deste processo.
PR: Antes tarde do que nunca.
148
DS: Elaboramos, planejamos, executamos e avaliamos projetos.
E agora? O que falta conhecermos sobre gerenciamento de
projetos?
MC: Lembra-se do ciclo de vida?
DS: Sim. Concepção, Planejamento, Execução e Controle, bem
como Encerramento.
MC: Então agora encerraremos o projeto. Dessa forma,
abordamos todos os processos do ciclo de vida de um projeto.
PR: O que fazemos primeiro?
MC: Esta última fase, ou último processo, consiste da
formalização do aceite do projeto e são encerrados os contratos
gerados durante sua execução. Outro ponto importante consiste
da medição e análise dos resultados após seu encerramento.
SB: Acabou o projeto. Ótimo. Toda a documentação gerada,
todos os problemas solucionados, o que fazemos com essas
informações?
MC: Registramos e documentamos como Lições Aprendidas.
PR: Mas como fazemos tudo isso?
MC: Vamos com calma. Uma coisa de cada vez.
149
Muitos gerentes de projetos entendem que, após a entrega do
projeto, este já está encerrado, e que mais nada precisa ser feito.
Não existe uma cobrança formal para o encerramento do projeto.
PR: O que é o encerramento administrativo?
MC: O encerramento administrativo consiste em documentar os
resultados do projeto para formalizar a aceitação do produto do
projeto pelos patrocinadores ou clientes. Isso inclui:
• a coleta dos registros do projeto, garantindo que eles reflitam as
especificações finais;
• análise do sucesso, efetividade do projeto;
• lições aprendidas e o arquivamento dessas informações para
uso futuro.
As atividades do encerramento administrativo não devem ser
retardadas até a conclusão do projeto. Cada fase do projeto deve
ser apropriadamente encerrada para assegurar que as
informações úteis e importantes não sejam perdidas.
DS: Você poderia explicar melhor?
MC: Claro. Vou tratar este assunto apresentando os
procedimentos desta fase. Acredito que assim o entendimento
seja melhor.
Em primeiro lugar, temos o Procedimento de encerramento
administrativo. Esse procedimento consiste das atividades para
encerrar o projeto internamente na organização.
PR: Quais são essas atividades?
MC: Trata-se da Documentação da medição do desempenho,
Documentação do Produto e outros registros inerentes ao projeto.
DS: Dê alguns exemplos.
MC: Temos então:
1. Documentação da medição do desempenho: toda a documentação
produzida para registro e análise do desempenho do projeto,
incluindo os documentos de planejamento que estabeleceram a
estrutura da medição do desempenho, deve estar disponível para
revisões durante o encerramento administrativo.
2. Documentação do produto: os documentos produzidos para
descrever o produto do projeto (planos, especificações,
documentação técnica, plantas, arquivos eletrônicos, etc.) devem,
também, estar disponíveis para revisões durante o encerramento
administrativo.
3. Outros registros do projeto: os registros devem incluir
150
correspondências, memorandos, relatórios e outros documentos
que descrevem o projeto. Essas informações devem, na medida
do possível, ser mantidas de modo organizado. Relatórios
formais do status do projeto e/ou pendências. E também
Apresentações do Projeto, onde a equipe do projeto fornece
informações formalmente e informalmente, para alguns ou todas
as partes envolvidas no projeto. A informação é relevante para as
necessidades de audiência e o método de apresentação
apropriado.
DS: Esta documentação reunida compõe o encerramento
administrativo.
MC: Exatamente. Mas temos também o Procedimento de
encerramento de contratos, que aborda os termos e condições
para finalizar os contratos de fornecimento realizados durante o
projeto.
Para os projetos nos quais se faz necessária a aquisição de bens
e serviços e, portanto, o gerenciamento de contratos entre cliente
e fornecedor, é também de suma importância o adequado
encerramento do contrato.
PR: O encerramento de contratos em gerenciamento de projetos é
diferente do encerramento no caso de aquisições nos nossos
processos internos?
MC: Na verdade, é basicamente a mesma coisa. Mas alguns
aspectos devem ser levados em conta.
PR: Quais aspectos?
MC: São basicamente os seguintes:
• a documentação para encerramento do contrato;
• Nota de Rescisão (quando for o caso),
• verificação de conformidade com procedimentos;
• auditoria de aquisições;
• aceitação e pagamento final; e
• arquivo do contrato.
DS: Você poderia explicar um pouco mais?
MC: Vamos lá.
(O texto a seguir foi extraído do seguinte livro: XAVIER, Carlos Magno da Silva et.
al. Gerenciamento de Aquisições
em Projetos. Rio de Janeiro: Editora FG, 2007)
151
São documentos necessários para o encerramento do contrato,
sob as perspectivas tanto do contratante quanto do contratado.
São exemplos de documentos usados no encerramento de
contratos:
• emitidos pelo contratante – relatório de encerramento do
contrato e termo de aceite;
• emitidos pelo contratado – atestado de inexistência de
reivindicações e relatório de encerramento do contrato.
Nota de rescisão
Auditoria de aquisições
152
O cliente procede à aceitação formal dos produtos ou serviços
objeto do fornecimento e efetiva o pagamento final ao fornecedor.
É verificado se todos os produtos e serviços constantes do
escopo do contrato foram entregues.
O fornecedor, após o recebimento da última fatura, deve fazer a
liberação de seguros-garantia ou carta de crédito.
Arquivo do contrato
2º - Formalização do encerramento
154
O término das atividades estabelecidas no contrato, também chamado
de terminação, se caracteriza pelo encerramento natural do
contrato, em decorrência do término de todas as obrigações ali
estabelecidas. As partes satisfeitas acertam as pendências finais
e dão-se quitações mútuas para nada mais reclamarem uma da
outra, seja a que título for, por si, seus herdeiros e sucessores.
Nessa oportunidade, o cliente emite a aceitação definitiva do
fornecimento e paga a integralidade do preço. Assim, se o
fornecedor tiver apresentado qualquer tipo de garantia (por
exemplo, uma caução bancária), esta retorna para o seu
patrimônio, ou parte dela é liberada, ficando apenas um
percentual para dar cobertura à garantia que ultrapassa o prazo
do contrato e se estende até o término do período e vigência ali
estabelecido. A situação se caracteriza pelo desempenho
satisfatório das partes, que se configura pelo fiel cumprimento de
todas as condições contidas no escopo do trabalho.
O acordo mútuo entre as partes, também chamado de resilição, é
a condição que envolve a vontade de ambas as partes na
extinção do contrato e que abrange não só a terminação, mas a
155
resolução. São situações em que as partes podem concordar em
encerrar o contrato, mesmo que os objetivos iniciais não tenham
sido atingidos. Nessa hipótese, as partes contratantes acertam a
forma de conclusão dos trabalhos pendentes, o recebimento de
parcelas devidas e o período predeterminado, quando elas se
obrigam a dar total quitação para as pendências cumpridas.
Neste caso, o cliente poderá contratar a finalização dos serviços
junto a terceiros, não podendo o ex-fornecedor exigir qualquer
indenização, seja a que título for.
A não-observância das condições no contrato, ou Resolução e
Rescisão, efetivam-se de forma unilateral e independente de
notificação judicial ou extra-judicial, gerando, como
conseqüência, o direito da parte prejudicada de exigir da outra o
pagamento de indenização por danos morais e/ou materiais.
Resolução é o evento que resolve o contrato em decorrência do
descumprimento de suas cláusulas e condições, porém
estabelece um prazo de aviso prévio para que as atividades em
andamento sejam concluídas. Rescisão é a ruptura do ajuste por
interesse de uma das partes, por descumprimento das
obrigações pela outra.
156
157
3º - Documentação das lições aprendidas
SB: Então, pela lógica, temos agora que documentar tudo o que
ocorreu com o nosso projeto?
MC: Isto mesmo, Been. Agora é hora de registrarmos toda a
aprendizagem obtida no processo de realização do projeto. Esse
documento é também chamado de registro das lições aprendidas.
PR: Como fazemos isso?
MC: É simples. Como disse agora mesmo, é muito importante que
“Cada fase do projeto deve ser apropriadamente encerrada para
assegurar que as informações úteis e importantes não sejam
perdidas”. Dessa forma já estamos armazenado as informações
para o relato final.
A teoria diz que documentar lições aprendidas é uma atividade
importantíssima durante qualquer projeto. Qualquer gerente de
projeto concordará com isso, mas nem sempre esta atividade é
realmente executada com a seriedade necessária.
DS: Sendo um aspecto tão positivo, por que isso acontece?
MC: É fácil entender porque as lições aprendidas são muitas
vezes deixadas de lado:
• Pressões para cumprir prazos: leva o gerente a se preocupar
mais com as atividades diretamente relacionadas ao produto do
projeto. Lembrem-se, eu falei que a fase de execução e controle
é mais cobrada, mas, depois de o produto ser entregue, existe
um relaxamento natural.
• Mudança de foco ao terminar um projeto: as pessoas e
organizações acabam mais concentradas no próximo projeto do
que no fechamento correto do projeto anterior.
• Falta de interesse da alta gestão neste tipo de documentos.
• Problemas culturais na empresa: levam o gerente a acreditar
que documentar lições aprendidas é uma perda de tempo, já que
não terá verdadeira influência sobre os próximos projetos da
organização.
158
ocorra e efetivamente trabalhar para uma boa documentação das
nossas atividades.
PR: Para mim, eu entendo que independente de todos esses
fatores, o gerente de projeto deve entender que as lições
aprendidas são uma ferramenta essencial para seu crescimento
profissional e para a melhoria contínua da organização.
SB: Falou o filósofo Rocha. Muito bom.
DS: Been, não começa.
MC: Vejo que vocês estão bem afinados com o nosso propósito.
Resumindo o que acabamos de falar, o registro das lições
aprendidas é muito mais do que um documento para cumprir a
formalidade do projeto. São as informações que permitirão que os
erros passados não se repitam e os acertos possam ser feitos
novamente.
DS: Por isso é importante registrar tanto as boas quanto as más
experiências do projeto. Esses registros ajudarão a moldar as
atividades e controles dos projetos futuros.
MC: Isso mesmo.
PR: Qual a melhor forma de fazermos isso?
MC: Segundo Luiz de Paiva, Consultor em Gerenciamento de
Projetos, a forma de fazer a documentação de lições aprendidas
varia muito de uma empresa para outra (ou de um projeto para
outro). A maioria das empresas, mesmo as que adotaram o
gerenciamento de projetos de uma forma ou outra, não possuem
uma forma única de criar esses registros. Cabe ao gerente de
projeto tomar a iniciativa para criar algo que seja:
• útil: se a informação não ajudará a empresa, equipe e gerente
nos próximos projetos, provavelmente não vale a pena registrá-la.
• prático: a forma de registro deve ser simples, ou a burocracia
tornará difícil o acompanhamento das lições aprendidas.
• compreensível: é importante que o gerente lembre que as
informações são para todos e que não deve cometer o erro de
documentar as informações de tal forma que somente ele
compreenderá.
DS: Na nossa metodologia, temos algum modelo que devamos
seguir?
MC: Temos, sim. Nesse modelo, avaliamos as áreas de
conhecimento em relação ao projeto executado.
DS: Como seria esse modelo?
MC: Aqui está. Nele descrevemos os aspectos positivos e
negativos em relação a cada item analisado.
159
160
PR: Esse modelo vai nos ajudar muito.
DS: Com certeza.
4º - Análise de indicadores de desempenho
161
PR: Esses são os indicadores mais avaliados hoje.
SB: Sem sombra de dúvidas.
MC: É isso aí, pessoal. Hora de colocar a mão na massa.
DS: Já temos alguma demanda específica?
MC: Temos sim, Delma.
DS: O que é?
MC: O Sr. Fortunato quer que elaboremos um Curso sobre
Gerenciamento de Projetos para divulgação na empresa. E aí,
vocês aceitam o desafio?
Todos: Claro que sim.
MC: Então mãos-à-obra. Primeiro passo?
SB: Elaboração do projeto para aprovação do Sr. Fortunato.
MC: Depois?
DS: Projeto aprovado, é hora de planejarmos.
PR: Vamos agora executar.
MC: Isso aí. Vamos depois registrar o nosso trabalho. Parabéns.
Vejo que entramos em sintonia.
PR: Parabéns a você, que tanto contribuiu para que
aprendêssemos a importância deste trabalho.
DS: Concordo com o Pedro.
SB: Eu também.
MC: Obrigada. Então vamos deixar de conversa e começar a
escrever o nosso primeiro projeto na metodologia da nossa
empresa.
Bibliografia/Links Recomendados
162
HARRIS, Simon. Powerful Magic with Gantt-Charts,
Microsoft Project and Excel. Project Manager Today, [s.l.], [s.n.], p.
27-29, may 2010. [Apresenta várias dicas no uso das ferramentas
de gerenciamento de projetos da Microsoft.]
JOHNSON, Ben; GARAGNA, Luciano. Frequently Forgotten
Work Packages. Project Manager Today, [s.l.], [s.n.], p. 24-25,
jan.-feb. 2010. [Lista atividades comuns em muitos projetos mas
que não costumam ser explicitadas nos cronogramas e EAPs.]
VARGAS, Ricardo V. Gerenciamento de Projetos:
Estabelecendo Diferenciais Competitivos. 6ª ed. Rio de Janeiro:
Brasport, 2005.
Vargas, Ricardo. Plano de Projeto – 3.ed. Rio de Janeiro:
Brasport, 2007.
163
164