gerencia de projetos - pos online 4

Prévia do material em texto

1ª Edição |Outubro| 2014
Impressão em São Paulo/SP
MS. José Ruy Veloso Campos
GERÊNCIA DE PROJETOS
Apresentação
O tema Gerência de Projetos tem tido várias 
abordagens nas duas últimas décadas. Ainda que di-
ferentes autores abordem a questão, sempre citando 
o PMBOK® Guide e suas normas, os olhares sobre 
o tema são diferentes.
Para alguns autores a questão matemática é fun-
damental. Assim, eles apresentam cálculos diversos 
sobre desempenho de custos, medidas do índice de 
desempenho, indicadores e outras fórmulas de aferir 
o desempenho na gerência dos projetos.
Para uma boa parte dos autores que estudaram 
o tema, o foco é sobre os conceitos e organização do 
modelo de gestão. 
Para a melhor compreensão do assunto, abor-
damos nesse instrumento didático a criação, con-
ceituação e organização de processos para a gestão 
exitosa de um projeto.
Longe de ser um trabalho conclusivo, o presen-
te instrumento é, antes de tudo, um guia para que 
o estudante possa buscar informações em diferen-
tes fontes que complementem esse trabalho. E mais 
proveitoso será para o leitor se essa busca for além 
das obras aqui citadas. 
Bom trabalho! 
Catalogação elaborada por Glaucy dos Santos Silva - CRB8/6353
Coordenação Geral 
Nelson Boni
Professor Responsável
MS. José Ruy Veloso Campos
Coordenadora Peda-
gógica de Curso- EAD
-
Coordenação de Projetos
Leandro Lousada
Revisão Ortográfica
Vanessa Almeida
Projeto Gráfico, Dia-
gramação e Capa
Ana Flávia Marcheti
1º Edição: Outubro de 2014
Impressão em São Paulo/SP
Gerência de projetos
Sumário
Capitulo 4
4.1 Estrutura Analítica do Projeto
4.2 Quem são os clientes
Categorias de clientes
4.3 Stakeholders
4.4 O escopo
4.5 A gestão da qualidade
O QFD – Quality Function Deployment
4.6 Projeto defensivo
O FMECA
4.7 Definindo atividades
4.8 Sequencia de atividades
4.9 Cronograma de Atividades
4.10 Roteiro para elaboração de projeto
Exercícios
Referências 51
07
Unidade 04
ETAPAS PARA O GERENCIAMENTO 
DO PROJETO
4.1 Estrutura analítica do projeto
A organização da estrutura analítica do projeto 
é um passo importante para a melhor compreensão 
do que será trabalhado no decorrer do projeto.
A estrutura analítica é uma relação dos produ-
tos ou serviços que serão desenvolvidos. Não deve 
ser confundida com uma relação de tarefas. 
Preferencialmente, o desenho da estrutura analí-
tica do projeto (EAP) se dá em forma de organogra-
ma, com os diferentes níveis bem claros e explícitos.
Tomemos como exemplo a organização de um 
Seminário sobre Gestão de Projetos:
8
 A EAP deve sempre retratar todos os entregá-
veis e não apenas o produto principal. Os entregá-
veis menores, no nível mais baixo da EAP, são cha-
mados de pacotes de trabalho. Pacote de trabalho é 
aqui entendido não como uma tarefa, mas sim como 
o menor produto que o projeto entrega. Isso está 
explícito no exemplo.
Numa outra representação temos a EAP do pro-
jeto de implantação de um novo produto numa em-
presa. Nesse caso, no primeiro nível, logo após o títu-
lo do projeto, aparecem as fases do projeto até a sua 
implantação. A depender do projeto, um período de 
acompanhamento pós-implantação pode ser previsto. 
Para Maximiano, p.59, 2010, é aconselhável ter 
diretrizes claras para a elaboração de uma EAP:
Diretrizes para Fazer a Estrutura Analí-
tica do Projeto
9
A definição, com clareza, de vários pontos do 
projeto que implicam em expectativas das partes in-
teressadas ou requisitos do cliente é da maior impor-
tância para o sucesso do trabalho do gestor.
Nessa perspectiva não podem ser negligencia-
dos TODOS os stakeholders. Alguém com visão 
diferente dos demais que não esteja bem informa-
do sobre os objetivos e metas do projeto podem vir 
a ser um obstáculo lá na frente, quando o projeto 
estiver numa fase na qual algumas mudanças sejam 
difíceis, senão impossíveis.
4.2. Quem são os clientes
Projetos têm clientes. Eles podem ser claros, 
explícitos ou apenas implícitos. 
10
O mercado, por exemplo, é um cliente, ainda 
que impessoal, pouco identificável, mas cujas carac-
terísticas podem estar bem definidas em pesquisas 
realizadas para aquele tipo de produto ou serviço.
Existem, ainda, os clientes que são específicos. 
Tomem-se como exemplo as empresas que precisam 
de um mesmo produto com especificações diferen-
ciadas em relação a alguns itens do produto/ serviço.
Como se vê pelo exemplo, um perfil diferencia-
do (que gerou um projeto) de um cliente pode trazer 
novas perspectivas para as empresas envolvidas.
Garantir a satisfação do cliente é um dos crité-
rios importantes para os bons resultados do projeto.
Para Kotler, p.187, 1999,
Uma empresa pratica “intimidade com o 
consumidor” quando é capaz de customizar seus 
produtos ou serviços de acordo com as exigências de 
determinado cliente... [ ] Algumas empresas customi-
zam seus produtos rotineiramente. Uma empresa que 
produz máquinas embaladoras projeta equipamentos 
11
especiais para atender às necessidades de embalagem 
do cliente. A Boeing projeta características e interio-
res de seus 747 de acordo com os desejos de cada 
companhia aérea que deve compra-los.
Para Maximiano, os clientes enquadram-se em 
três categorias:
• Clientes que usam e pagam. É o caso de pessoas 
ou organizações que utilizarão diretamente o produ-
to do projeto. Por exemplo, o empresário que enco-
menda uma revisão na estrutura organizacional de 
sua empresa ou a família que encomenda uma casa 
ao arquiteto.
• Clientes que usam e não pagam. É o caso dos usuá-
rios de projetos encomendados pelas organizações em 
que trabalham. Por exemplo, os funcionários que utili-
zam um sistema de informações ou dos operadores de 
um equipamento. Também são clientes dessa categoria 
os beneficiários de projetos patrocinados por órgãos de 
financiamento ou fundações filantrópicas.
• Clientes que não usam e pagam. É o caso de pesso-
as ou organizações que encomendam projetos para 
que outros utilizem o produto. Por exemplo, os pa-
trocinadores de projetos filantrópicos ou os direto-
res de uma empresa que encomendam projetos de 
novos produtos a sua divisão de engenharia. 
12
4.3 Stakeholders
Stakeholders, como já visto no presente traba-
lho, são todos aqueles que participam direta ou in-
diretamente de um projeto ou estão nele envolvidos 
de alguma forma.
Ainda que o foco principal de determinados 
projetos seja o cliente, alguns projetos exigem a par-
ticipação de todos os stakeholders relevantes. 
Quando se trata de um projeto que envolve “a 
coisa pública”, aqui entendida como qualquer local, 
obra ou espaço que se destine ao uso público, essa 
participação é fundamental. (Se é certo que nem 
sempre o povo é consultado, é certo também que tal 
omissão pode gerar grandes problemas, pela via jurí-
dica, como já foi citado neste trabalho). Os casos re-
lativamente recentes do design dos ônibus urbanos 
mais “amigáveis” para pessoas com dificuldades de 
locomoção como deficientes e idosos são um bom 
exemplo disso. Diferentes associações, médicos e 
especialistas foram consultados e tiveram suas opi-
niões e depoimentos registrados e assinados.
Já com obras viárias ou qualquer outra obra pú-
blica, as questões ambientais, ainda que observadas, 
acabam questionadas e podem causar interrupção 
das obras, causando prejuízo para quem a constrói 
e, sobretudo, para o usuário.
E por que diferentes stakeholders devem ser 
13
consultados num projeto privado?
Exatamente para se evitar reclamações e obstá-
culos futuros à produção dos produtos ou serviços-
-objeto dos projetos.
Tomando como base o exemplo dos biscoitos 
em “embalagens individuais”, (acima) imagine-se 
que para essa produção tenham sido necessárias mu-
danças estruturais numa planta fabril, ou pelo menos 
alterações nos equipamentos de produção. Isso tudo 
impacta em custos e mudanças que podem envolver 
pessoas, jornadas de trabalho, fornecedores, etc. Há, 
portanto, que se deixar claro para todos os stakehol-
ders (e,às vezes, para os shareholders [acionistas]) as 
mudanças necessárias e suas implicações.
Maximiano, p.60, 2010, lista algumas perguntas 
que devem ser feitas às partes interessadas, a saber:
• Qual deverá ser a situação ao final do projeto? O 
que, precisamente se pretende alcançar?
• Por qual motivo esse objetivo deve ser alcançado?
• A que necessidades específicas esse objetivo deve 
atender? Qual problema deve resolver? Qual opor-
tunidade deve aproveitar?
• Se a situação inicial é um problema, qual a estrutura 
de causas e efeitos? Quais os efeitos indesejáveis a 
serem corrigidos? Em quais causas se deve interferir 
para corrigir os efeitos indesejáveis?
• Quem é o afetado por esse problema?
14
• Quem é o cliente ou usuário do produto do pro-
jeto? Quem está pagando? Quem paga é quem vai 
usar a solução?
• Quem, no final do projeto, é responsável pela apro-
vação do produto?
Em qualquer situação de prestação de serviços 
é importante que perguntas sejam feitas. É preciso 
que o prestador de serviços tenha claro para si as in-
tenções do contratante, que conheça as partes inte-
ressadas e seus eventuais diferentes pontos de vista.
4.4. O escopo
Como já foi visto, o escopo é a definição da-
quilo que será desenvolvido no projeto. Quando o 
trabalho do projeto é iniciado é imperativo que haja 
um controle do escopo.
Não é incomum que ocorram alterações no 
escopo. Não se trata de “falta de planejamento” a 
ocorrência de alterações no escopo. Como já foi vis-
to nesse trabalho, o próprio planejamento é dinâmi-
co e dessa forma, alterações são mais comuns do 
que se pode imaginar.
As obras de construção civil costumam apre-
sentar mudanças em seus projetos, o que não signi-
fica que o original não fosse correto. As mudanças, 
em geral, ocorrem por conta de adequações à reali-
15
dade dos usuários, da legislação, da topografia ou da 
região geográfica da obra.
Algumas questões se impõem para a checagem 
dos objetivos quanto ao escopo, senão vejamos:
• O projeto segue o rumo conforme o planejado?
• No modelo em curso, o projeto entregará os pro-
dutos planejados?
• Existem modificações? Quem as solicitou (sugeriu)?
No cronograma de trabalho de um grupo de 
projetos devem constar reuniões de follow-up com 
o cliente e outros interessados. Essas reuniões po-
dem evitar despesas imprevistas e mal entendidos no 
final do processo.
Mudanças, mesmo aquelas com as quais os ges-
tores do projeto eventualmente não concordem, se 
têm que ocorrer, é melhor que ocorram durante o 
processo. No caso de produtos, depois da constru-
ção de um protótipo os custos são bem maiores do 
que a fase de elaboração de projeto no papel. Não 
que não se possa alterar o protótipo (afinal, para isso 
trata-se de um protótipo), mas estamos tratando de 
tempo e custos.
Para evitar maiores problemas nesse aspecto, é 
interessante que alguns limites sejam estabelecidos 
quanto às possíveis mudanças no escopo. Empresas 
familiares, onde os shareholders são consanguíneos 
16
e, em geral, trazem suas diferenças pessoais para a 
arena empresarial os projetos podem sofrer a inter-
ferência de idiossincrasias das pessoas do grupo. E, 
assim, as mudanças num escopo viram uma disputa 
de outra ordem. 
Um limite contratual nesse quesito ajuda o ges-
tor do projeto a conduzir com maior probabilidade 
de sucesso essas possíveis diferenças.
Controlando o escopo
O escopo é o que define todo o projeto e, por 
conseguinte, os seus processos. No escopo baseiam-
-se os processos da administração das outras variá-
veis como custos, prazos, riscos, qualidade e outras. 
Maximiano, p.62, 2010, recomenda uma avalia-
ção muito bem definida com os stakeholders antes 
de iniciar definitivamente o projeto. Isso, certamen-
te, evitará custos e desperdício de tempo futuros.
O checklist a seguir é adaptado de Gray; Lar-
son, 2003, apud Maximiano:
• Estão bem definidos os objetivos do projeto? O obje-
tivo da missão do projeto compreende a declaração do 
escopo, definido o produto principal a ser fornecido?
• Há uma lista preliminar de entregáveis com a qual 
todos estejam de acordo? Há uma EAP de consenso?
• As justificativas do projeto são lógicas e foram 
aceitas?
• Os requisitos técnicos estão definidos? Os requi-
17
sitos técnicos definem o nível de desempenho ou 
capacidade do produto que o projeto entregará. São 
criados com base nas expectativas do cliente (ou 
“voz do cliente”) e constituem a base para o pro-
cesso de administração da qualidade do projeto. Na 
fase inicial do planejamento do projeto, os requisitos 
técnicos são abrangentes, explicando apenas o que 
o produto deverá ser capaz de fazer. Por exemplo: o 
sistema deverá ser capaz de processar 2.000 pedidos 
por dia; a casa deverá ter dois apartamentos e um 
estúdio, pelo menos.
• Estão definidos os marcos do projeto? Os marcos 
(ou milestones) são pontos importantes no ciclo de 
vida do projeto. Pode ser um evento, o início ou o 
fim de uma atividade, ou uma data na qual o docu-
mento deve ser assinado, uma parcela do orçamento 
que deve ser liberada, e assim por diante.
• Estão definidas as exclusões do escopo? O plano 
deve explicitar o que o projeto não vai fazer – quais 
produtos não serão entregues ou quais objetivos não 
serão realizados.
O que precisa ficar claro na elaboração do pla-
nejamento (e na proposta de trabalho) de um proje-
to, a respeito do escopo:
• O escopo tem a dimensão e abrangência dos pro-
dutos/serviços do projeto;
18
• A declaração do escopo é uma definição dos obje-
tivos, produtos ou serviços do projeto;
• O detalhamento do escopo constitui a divisão de 
produtos/serviços do projeto até o nível dos paco-
tes de trabalho;
• Apontar a exclusão, isto é, o que NÃO SERÁ EN-
TREGUE, é importante, por mais que possa parecer 
óbvio para os gestores do projeto;
• É importante que a equipe tenha a Estrutura Ana-
lítica do Projeto. Essa representação gráfica ajuda no 
detalhamento do escopo;
• Uma EAP com a lista de entregáveis também é impor-
tante (listados também os NÃO ENTREGÁVEIS);
• A organização visual do pacote de trabalho ajuda 
igualmente na compreensão do escopo.
4.5. A Gestão da Qualidade
No processo de gestão de projetos, como em 
qualquer atividade que se realize na vida, é preciso 
ter o foco na qualidade. Para que isso seja possível, 
é necessário que algumas regras sejam seguidas. Co-
mecemos com o conceito de qualidade. Para Maxi-
miano, p. 66, 2010:
Qualidade é um conjunto de características (ou espe-
cificações) de uma entidade, (produto, serviço, even-
to, conceito, pessoa, grupo, organização). As carac-
19
terísticas definem a capacidade de a entidade atender 
necessidades implícitas ou explícitas.
O gerenciamento da qualidade de um produ-
to ou serviço parte da definição das especificações 
desejadas para aquele produto ou serviço. Foi o que 
fez o sistema ISSO nos anos 1990, sistematizou pro-
cedimentos que garantem a qualidade no decorrer e 
ao final do processo.
Na gestão do projeto, qualidade significa conciliar 
os interesses do cliente com os de todos os stakeholders. 
As partes interessadas no projeto/produto/
serviço constituem toda a cadeia:
• Usuário ou consumidor
• Distribuidores, vendedores, pessoal de manuten-
ção e assistência
• Linha de produção
• Outros
Maximiano, p.67, 2010, entende que o produto 
deve incorporar as seguintes especificações:
• Design for manufacturability: Projeto ou desenho 
para a produtibilidade – ou facilidade de fabricação
• Design for assembly: projeto ou desenho para mon-
tagem – ou facilidade para a montagem do produto
20
• Design for serviceability and maintainability: pro-
jeto ou desenho para serviço e manutenção – ou fa-
cilidade de fazer manutenção do produto.
Por qualidade, entenda-se, além das áreas fun-
cionais das empresas envolvidas no processo, mais 
cliente/consumidor, também o ambiente e os im-
pactos econômicos e sociais que o produto ou ser-
viço vai acarretar. 
O alcance da qualidade envolve todo o proces-
so do ciclo de vida doprojeto e do próprio produto/
serviço em si, e os seus desdobramentos.
Na gestão do projeto o foco da qualidade reside 
em “gerenciar a qualidade do gerenciamento”.
No IPMA Competence Baseline, apud Maxi-
miano, p. 69, 2010, qualidade é apontada como uma 
das competências técnicas, assim definida:
A qualidade do projeto é definida como o atendimento 
dos requisitos acordados para o projeto. A qualidade 
da administração do projeto é definida como o atendi-
mento dos requisitos acordados para a administração 
do projeto [...] A base da qualidade do projeto é for-
mada pelas práticas da administração da qualidade da 
organização permanente [...] Especificamente, a orga-
nização permanente determina a política, os objetivos 
e as responsabilidades da qualidade do projeto.
21
O uso das áreas do conhecimento e os processos 
do Guia do PMBOK ajudam na melhor definição de 
especificações de desempenho relativo à qualidade na 
gestão de projetos.
A gestão da qualidade envolve diferentes pro-
cessos que devem incluir o 
• Planejamento da qualidade, a 
• Garantia da qualidade e o 
• Controle da qualidade. 
Planejar implica na definição do produto/ser-
viço e suas características. Essa definição se dá com 
base na análise das necessidades. 
A qualidade planejada abarca as especificações 
funcionais e as especificações técnicas.
As especificações funcionais, também chama-
das de especificações de desempenho, devem tra-
duzir as necessidades e expectativas do cliente em 
relação àquilo que o produto deve alcançar. 
Elas descrevem o produto na linguagem do 
cliente. Essa linguagem não é técnica. Trata-se do 
resultado da Voz do Cliente que o pessoal técnico 
deve ouvir para chegar às especificações técnicas.
Exemplos de especificações funcionais:
22
• Capacidade de carga de um equipamento
• Tamanho de um eletrodoméstico
• Velocidade de um veículo
• Clareza de um manual
• Potência e duração de uma bateria para computa-
dores ou celular
As especificações técnicas surgem a partir das es-
pecificações funcionais. Elas descrevem as característi-
cas do produto em relação aos seus atributos técnicos.
Exemplo de especificações técnicas:
• Dimensões de um equipamento ou objeto;
• Processo de fabricação de determinado produto;
• Capacidade de memória de computadores ou celulares;
• Número de HP de um motor e caixa de mudanças 
de um veículo.
23
Garantia da qualidade
Como visto, qualidade é a jornada, não o destino. 
E, nesse caso, o da gestão de projetos, a jornada é o 
processo. Garantir a qualidade significa fazer coinci-
dir a qualidade planejada com a qualidade real. E isso 
tem que ocorrer durante o processo de elaboração do 
projeto, enquanto ainda é possível corrigir os defeitos. 
Também como já visto, depois de pronto um protóti-
po, por exemplo, é sempre mais cara a correção.
A garantia da qualidade se dá através da estru-
turação de um sistema de qualidade.
Um sistema de qualidade contempla:
• Padrões (as especificações);
• Procedimentos de análises para evitar erros no fi-
nal do processo;
• Qualificação do pessoal;
• Definição de responsabilidades pela qualidade em 
cada etapa;
• Testes e simulações;
• Manuais da gestão da qualidade. 
A implementação de um sistema de qualidade inde-
pende do seu grau de sofisticação. O importante é que 
haja um conjunto de normas. E que elas sejam obedecidas.
24
A eficiência do sistema de qualidade está em as-
segurar que o resultado correto seja obtido.
O QFD - Quality Function Deployment 
O QFD (Quality Function Deployment, ou 
Desdobramento da Função Qualidade) é uma das 
ferramentas da qualidade que foi criada na década 
de 1960 pelo japonês Yoji Akao, e que tem como 
objetivo principal permitir que a equipe de desenvol-
vimento do produto incorpore as reais necessidades 
do cliente em seus projetos de melhoria.
A primeira indústria a aplicá-lo foi a Mitsubishi 
Heavy em 1972. Em 1983, o método chegou aos 
EUA e foi amplamente divulgado a partir dos anos 
80. As pioneiras americanas a adotar o método fo-
ram a Ford e a Xerox.
O QFD é uma ferramenta que possibilita “ou-
vir” a voz do cliente e ordená-la de modo a facilitar a 
análise de suas necessidades que são transformadas 
25
em requisitos para a melhoria do produto na forma 
de especificações técnicas do mesmo. 
A matriz original de Akao está abaixo para me-
lhor compreensão. Observe-se que trata-se de uma 
leitura com os mesmos princípios do planejamento.
Seguindo as perguntas propostas no QFD é 
possível identificar as necessidades do cliente. 
Dessa forma, a equipe da gestão do projeto 
deve fazer o levantamento das especificações fun-
cionais através de pesquisa que aponte para aquilo 
que o cliente/consumidor espera que seja entregue 
no produto final.
26
Para isso, é interessante que as especificações 
funcionais sejam agrupadas por afinidade. Tome-se 
como exemplo um novo modelo de aspirador de pó.
Nem sempre as especificações têm o mesmo peso 
e importância para o consumidor/usuário. Nesse caso, 
é possível estabelecer uma tabela de peso/grau de im-
portância para cada um dos itens apontados.
Numa escala de 1 a 5, por exemplo, onde:
1= muito pouco importante
5= muito importante
Tabela com avaliação do consumidor/usuário
27
Esse tipo de avaliação pode ser feito através de 
pesquisa qualitativa ou com questionário simples. A 
metodologia da pesquisa qualitativa enseja a oportu-
nidade de ouvir melhor e em maior tempo a opinião 
do consumidor/usuário sobre o produto ou serviço 
em questão.
Relação entre as necessidades e características técnicas
A avaliação, pelo consumidor/usuário deman-
da a elaboração de uma matriz que cruzará as neces-
sidades identificadas com as características técnicas.
Tome-se como base a tabela acima com a avalia-
ção do consumidor/usuário e é possível atribuir uma 
escala de grau de importância para cada item levantado.
Assim, é possível avaliar percentualmente se a 
característica apresentada é de fato relevante para o 
consumidor/usuário.
Observe-se que os itens Duas Velocidades e 
Grelha de Ventilação Grande não tem 50% de grau de 
importância na visão desses consumidores/usuários.
Já o nível de ruído apresenta uma importância 
de 100%, enquanto nos itens relativos à segurança 
ficam entre 60% e 100%.
Qualquer que seja o alvo do projeto, um pro-
duto ou serviços, essa avaliação é importante porque 
“ouve o cliente/consumidor/usuário”. 
Observe-se que a pesquisa sobre o assunto é 
feita com usuários desses produtos ou serviços. E 
ninguém melhor do que eles, usuários, para dizer o 
28
que é mais importante num produto ou serviço.
4.6. Projeto defensivo
O projeto defensivo (defensive design) trabalha 
práticas que visam assegurar que o produto NÃO 
TENHA especificações que possam causar danos ao 
consumidor/usuário. 
São projetos defensivos as travas das portas tra-
seiras dos automóveis de passeio a partir do coman-
do do motorista. Trata-se de uma proteção preven-
tiva às crianças no banco traseiro que podem abrir a 
porta com o veículo em movimento.
Tampas de medicamentos ou produtos de lim-
peza que podem causar mal à saúde também são do-
tadas de “segredos” para a abertura como girar no 
sentido horário ou apertá-las contra a embalagem. 
Esses mecanismos evitam o acesso de crianças aos 
produtos e evitam eventuais vazamentos.
Os projetos defensivos buscam evitar ocorrên-
cias prejudiciais ao consumidor/usuário. Tais práti-
cas devem ser trabalhadas no começo dos projetos, 
seja o alvo um produto manufaturado ou um serviço.
No caso dos serviços, as recomendações para o 
usuário devem ser claras e nítidas com antecedência 
ao uso do serviço.
São medidas defensivas na área de serviços 
as recomendações sobre dieta ou procedimentos à 
29
véspera de exames laboratoriais com alguma com-
plexidade. A desobediência às recomendações pode 
alterar o resultado do exame de sangue, de urina ou 
mesmo de imagens feitas do corpo humano, ou pro-
vocar um choque indesejado no paciente.
Também na área de serviços,são ferramentas 
defensivas os avisos para uso de equipamentos de 
transporte ou de lazer, como trens, metrô, ônibus, 
aviões ou brinquedos de parques de diversões. 
As recomendações nos parques de diversões 
da Disney, por exemplo, fazem parte dos contra-
tos de seguro que a organização mantém. Logo, se 
um usuário colocar os braços para fora de um dos 
brinquedos desobedecendo os avisos claros e as re-
comendações feitas em vídeos e pelos monitores, é 
bem possível que a mantenedora dos parques e suas 
seguradoras se recusem a pagar pelos danos causa-
dos ao usuário.
O FMECA
A análise dos modos, efeitos e criticidade das 
falhas (Failure modes, effects and criticality analysis 
– FMECA) é também uma das ferramentas do pro-
jeto defensivo. 
É também considerada uma ferramenta útil no 
princípio de “fazer certo na primeira vez”, dentro da 
moderna gestão da qualidade. 
30
A primeira versão dessa ferramenta surgiu no 
final da década de 1940, criada pelos militares dos 
Estados Unidos. Originalmente, era apenas FMEA 
(Failure modes and effects analysis).
Da mesma forma que se estabelece um padrão 
numérico para medir a relação entre necessidades e 
características técnicas, adota-se, aqui, uma escala 
com cinco níveis, a saber:
1. Frequente
2. Razoavelmente provável
3. Ocasional
4. Remota
5. Extremamente improvável
Seguindo tal lógica, têm-se os graus de severi-
dade e intensidade que se traduzem na medida de 
impacto causado pela falha ou pelo problema que 
surge. Trata-se de uma escala de quatro pontos.
1. Catastrófico: quando a falha pode causar 
mortes de pessoas ou perda total de equipamentos 
ou sistemas;
2. Crítico: quando a falha pode provocar feri-
mentos sérios ou danos de grande porte em equipa-
mentos, propriedades ou sistemas, resultando daí a 
impossibilidade de realizar a missão original;
3. Marginal: quando a falha pode provocar fe-
31
rimentos leves ou danos de pequeno porte em equi-
pamentos ou sistemas, resultando em atrasos da 
missão, perda de oportunidade ou degradação da 
missão original;
4. Insignificante: quando a falha não provoca 
ferimentos ou danos, mas que exige consertos ou 
manutenções não programadas.
Em qualquer projeto essa previsão é necessária.
Sabe-se que as turbinas dos aviões não foram 
feitas para sugar pássaros. Tampouco os vidros da 
cabine de comando dessas aeronaves foram feitos 
para suportar batidas de aves em pleno voo.
Certamente, os fabricantes de aviões têm uma 
análise perfeita para o enfrentamento de tal proble-
ma e os riscos que advêm de tal incidente.
Da mesma forma, ainda que até hoje seja im-
possível prever com antecedência, numa rodovia, o 
trecho que pode provocar uma aquaplanagem, os 
fabricantes de carros buscam meios de dar maior 
estabilidade e proteção aos passageiros dos veícu-
los. Nessa perspectiva, milhares de testes são feitos 
constantemente pelas fábricas no mundo todo.
Um plano de administração da qualidade não 
tem padrões definidos. Vai sempre depender do pro-
jeto e de seus fatores condicionantes.
Uma planilha mínima, com dados como produ-
to/processo; função; falha do material; consequências 
32
da falha; causas da falha; modo de detecção; frequên-
cia; severidade; probabilidade da detecção; número de 
riscos; ações corretivas e suas responsabilidades, de-
verá servir como norteador para eventuais problemas 
com a qualidade e documentação do plano.
A elaboração do plano e sua planilha será, ob-
viamente, inspirada nas particularidades do projeto, 
seja ele sobre um produto ou serviço.
4.7. Definindo as atividades conforme os objetivos
Como foi visto no primeiro capítulo, a defini-
ção dos objetivos é fundamental para a avaliação de 
um projeto. Uma vez definidos os objetivos, é pre-
ciso explicitá-los nas diferentes partes do plano de 
desenvolvimento do projeto.
Começa-se, então, a definição das atividades 
com os prazos e a definição do tempo do trabalho. 
Segue a definição dos recursos que, por sua vez, 
vai definir os custos do projeto. Para a administração 
dos prazos o cronograma é a principal ferramenta. 
Para a gestão dos custos é necessária a elaboração do 
orçamento do projeto.
Como se sabe, prazos e custos são as formas de 
consolidar os entregáveis. Então, tem-se que: Pro-
duto, prazos e custos são os principais elementos do 
plano e das ações gerenciais de um projeto.
Para organizar decisões e tarefas do planeja-
33
mento dos meios para a realização do projeto é pre-
ciso seguir uma ordem:
• Definição das ações e atividades;
• Definição da cronologia dessas atividades;
• Construção do cronograma de atividades;
• Identificação dos recursos necessários e disponíveis;
• Definição dos custos desses recursos;
• Elaboração do orçamento do projeto.
Definindo as atividades
Para a definição das atividades é importante o 
uso da EAP, estrutura analítica do projeto, que foi 
vista páginas atrás. Tome-se como base o exemplo já 
dado, a organização de um Seminário Sobre Gestão 
de Projetos: 
Numa visão analítica, é possível a visualização 
de cada entregável e as diferentes atividades que são 
necessárias para a entrega.
O exemplo a seguir pode, ainda, conter maior 
detalhamento de cada entregável.
34
• Título do Projeto (Seminário sobre Gestão de Projetos)
• 1º nível entregável (Palestras)
• 2º nível entregável (Palestrantes)
• 3º nível entregável (inscrições; orientação para di-
ferentes abordagens; identificação; apoio para trans-
porte, alimentação e alojamento)
Temos, então, uma estrutura com três níveis 
mais o título do serviço. O último nível, como sem-
pre, é o nível dos Pacotes de Trabalho. Para a re-
dação da estrutura, use sempre substantivos e não 
verbos. A estrutura analítica é sempre uma relação 
de produtos e não de tarefas ou atividades.
4.8 Sequência das atividades
35
É importante que os gestores tenham claras as 
sequências do projeto, considerando o seu ciclo de 
vida. Lembrando que o ciclo de vida permite a visuali-
zação de atividades que podem não estar diretamente 
ligadas ao produto/serviço em sua estrutura analítica. 
Dessa forma, manter uma rotina de reuniões 
sobre o planejamento e controle, visitar os fornece-
dores e analisar o cenário físico das obras, por exem-
plo, permitem aos gestores um controle melhor de 
todas as atividades correlatas.
O controle do ciclo de vida permite previsões 
sobre riscos e acidentes, testes e experimentação e 
períodos do tempo (datas e estações do ano) que de-
vem ser evitadas, adiadas ou antecipadas.
Nas obras rodoviárias, por exemplo, a estação 
chuvosa é obstáculo para determinadas fases da 
construção, como a compactação do solo. As em-
presas procuram adiantar ou retardar essas etapas 
levando em conta as previsões normais de chuvas e 
o calendário da entrega da obra.
Feriados ou grandes eventos (carnaval, sema-
na santa, Copa do Mundo) são outros obstáculos às 
operações de rotina em um determinado projeto, seja 
ele de construção civil, teste de um novo produto ou 
a realização de um evento na área de serviços. Todos 
eles podem sofrer a interferência, nem sempre dese-
jada das datas, eventos ou estações climáticas.
36
4.9. O Cronograma das atividades
Como se sabe, o cronograma é um gráfico que 
mostra a distribuição das atividades no calendário 
do projeto. Trata-se de uma fotografia da cronologia 
do tempo baseado nas decisões do planejamento. O 
processo de tomar as decisões de cronologia, que 
equivale associar o trabalho ao transcurso do tempo, 
é conhecido também como cronogramação. 
A preparação do cronograma baseia-se na du-
ração das atividades. E como visto no tema do Ciclo 
de Vida do Projeto, a estimativa da duração das ati-
vidades depende de lógica, decisão, condicionantes 
externos e outros fatores, a saber:
Recursos: Os recursos suficientes formam a 
base para o sucesso de um projeto. Em tese, quan-
to maior a disponibilidade de recursos, sejam eles 
financeiros ou de pessoal, maior a probabilidade de 
sucesso da missão do grupo gestor.
Participação de terceiros: Todosos grandes 
projetos contam com a participação de serviços ter-
ceirizados. Pode ser um cálculo de estrutura para 
uma grande obra da construção civil, um simples 
vídeo institucional ou o transporte rotineiro de pes-
soas ou produtos. Esses terceiros estão sujeitos aos 
seus próprios problemas e que podem interferir no 
andamento do cronograma. Como visto no Ciclo de 
Vida, esses atores (terceiros) devem ser acompanha-
37
dos com regularidade para que um eventual proble-
ma em suas áreas não venha a afetar e comprometer 
o andamento do projeto.
Cuidados no planejamento: A data limite para 
alguns projetos obriga os gestores a fazerem um cro-
nograma invertido, do final para o começo. Tome-se 
como prazo para a entrega de fantasias para um blo-
co de carnaval. A data limite é de uma semana antes 
do carnaval.
Não existem outras possibilidades de renego-
ciação de prazos. A entrega tem data inamovível. 
Então, trabalha-se com o calendário invertido, a par-
tir da data de entrega para trás.
Em outras situações de prazos que permitem 
alguma flexibilidade, como já visto neste trabalho, é 
preciso considerar as variáveis não controláveis que 
podem ocorrer como instabilidades climáticas, polí-
ticas, econômicas etc. São aquelas que compõem o 
Ambiente Externo das empresas.
Maximiano, p. 96, 2010, recomenda o Diagra-
ma de Redes:
Diagramas de redes são diagramas de precedências 
com informações sobre a duração das atividades e so-
bre o caminho crítico. O caminho crítico é o caminho 
mais longo que leva da primeira à última atividade de 
um projeto – aquele no qual as atividades têm a dura-
ção mais extensa. Os caminhos ou ramos da rede que 
38
têm durações mais curtas precisam esperar o caminho 
crítico terminar para poderem continuar. Vejamos um 
exemplo com uma forma simples de rede. Suponha 
que alguém tenha decidido começar uma empresa co-
mercial e precise realizar cinco atividades, que são as 
seguintes, com as respectivas durações e dependências:
Já dá para perceber que o caminho crítico passa pela 
atividade 3, a parte legal e burocrática da abertura da 
empresa. A inauguração, que é a entrega do produ-
to, depende dessa atividade crítica. Como as demais 
atividades têm duração menor, podem ser atrasadas, 
para esperar a atividade crítica terminar. No entanto, 
se houver atraso no caminho crítico, a entrega do pro-
duto será atrasada. Portanto o empreendedor precisa 
pagar as “taxas de urgência e incentivos” para manter e 
até mesmo acelerar o caminho crítico.
4.10. Roteiro para a elaboração de um plano 
de projeto
39
40
41
Para completar as informações relativas ao ro-
teiro do projeto e sua execução, leia com atenção e 
detalhes os capítulos 08 e 09, de Maximiano, 2010.
Neste capítulo vimos:
• Etapas para o gerenciamento do projeto
A estrutura analítica é uma relação dos produ-
tos ou serviços que serão desenvolvidos. Não deve 
ser confundida com uma relação de tarefas
Estrutura Analítica do Projeto EAP
A EAP deve sempre retratar todos os entregá-
veis e não apenas o produto principal. Os entregá-
veis menores, no nível mais baixo da EAP, são cha-
mados de pacotes de trabalho. Pacote de trabalho é 
aqui entendido não como uma tarefa, mas sim como 
o menor produto que o projeto entrega.
• Quem são os clientes
42
Projetos têm clientes. Eles podem ser claros, 
explícitos ou apenas implícitos. 
O mercado, por exemplo, é um cliente, ainda 
que impessoal, pouco identificável, mas cujas carac-
terísticas podem estar bem definidas em pesquisas 
realizadas para aquele tipo de produto ou serviço.
Existem, ainda, os clientes que são específicos. 
Tomem-se como exemplo as empresas que precisam 
de um mesmo produto com especificações diferen-
ciadas em relação a alguns itens do produto/ serviço.
• Categorias de clientes
Clientes que usam e pagam. É o caso de pes-
soas ou organizações que utilizarão diretamente o 
produto do projeto. 
Clientes que usam e não pagam. É o caso dos 
usuários de projetos encomendados pelas organiza-
ções em que trabalham. 
Clientes que não usam e pagam. É o caso de 
pessoas ou organizações que encomendam projetos 
para que outros utilizem o produto. 
• Stakeholders
Stakeholders são todos aqueles que participam 
direta ou indiretamente de um projeto ou estão nele 
envolvidos de alguma forma.
43
• O Escopo
O escopo é a definição daquilo que será desen-
volvido no projeto. Quando o trabalho do projeto é 
iniciado é imperativo que haja um controle do escopo.
• A gestão da qualidade
No processo de gestão de projetos, como em 
qualquer atividade que se realize na vida, é preciso 
ter o foco na qualidade. Para que isso seja possível, é 
necessário que algumas regras sejam seguidas. Qua-
lidade é um conjunto de características (ou especifi-
cações) de uma entidade, (produto, serviço, evento, 
conceito, pessoa, grupo, organização). O gerencia-
mento da qualidade de um produto ou serviço parte 
da definição das especificações desejadas para aquele 
produto ou serviço. Foi o que fez o sistema ISSO nos 
anos 1990, sistematizou procedimentos que garantem 
a qualidade no decorrer e ao final do processo.
Na gestão do projeto, qualidade significa con-
ciliar os interesses do cliente com os de todos os 
stakeholders.
• O QFD – Quality Function Deployment
O QFD (Quality Function Deployment, ou 
Desdobramento da Função Qualidade) é uma das 
44
ferramentas da qualidade que foi criada na década 
de 1960 pelo japonês Yoji Akao e que tem como 
objetivo principal permitir que a equipe de desenvol-
vimento do produto incorpore as reais necessidades 
do cliente em seus projetos de melhoria.
A primeira indústria a aplicá-lo foi a Mitsubishi 
Heavy em 1972. Em 1983 o método chegou aos 
EUA e foi amplamente divulgado a partir dos anos 
80. As pioneiras americanas a adotar o método fo-
ram a Ford e a Xerox.
• Projeto defensivo
O projeto defensivo (defensive design) trabalha 
práticas que visam assegurar que o produto NÃO 
TENHA especificações que possam causar danos ao 
consumidor/usuário. 
São projetos defensivos as travas das portas tra-
seiras dos automóveis de passeio a partir do coman-
do do motorista. Trata-se de uma proteção preven-
tiva às crianças no banco traseiro que podem abrir a 
porta com o veículo em movimento.
• O FMECA
A análise dos modos, efeitos e criticidade das 
falhas (Failure modes, effects and criticality analysis 
– FMECA) é também uma das ferramentas do pro-
45
jeto defensivo. 
É também considerada uma ferramenta útil no 
princípio de “fazer certo na primeira vez”, dentro da 
moderna gestão da qualidade. 
A primeira versão dessa ferramenta surgiu no 
final da década de 1940, criada pelos militares dos 
Estados Unidos.
• Definindo atividades
A definição dos objetivos é fundamental para a 
avaliação de um projeto. Uma vez definidos os obje-
tivos é preciso explicitá-los nas diferentes partes do 
plano de desenvolvimento do projeto.
Começa-se então a definição das atividades 
com os prazos e a definição do tempo do trabalho. 
Segue a definição dos recursos que, por sua vez, 
vai definir os custos do projeto.
Para a administração dos prazos o cronograma 
é a principal ferramenta.
• Sequência de atividades
É importante que os gestores tenham claras as 
sequências do projeto considerando o seu ciclo de 
vida. Lembrando que o ciclo de vida permite a visuali-
zação de atividades que podem não estar diretamente 
ligadas ao produto/serviço em sua estrutura analítica.
46
• Roteiro para elaboração do cronograma 
Os passos para a elaboração do cronograma de 
seu projeto.
47
48
49
Exercícios
1. Explique por que a EAP, Estru-
tura Analítica do Projeto, é impor-
tante para a gestão dos projetos.
2. Quem são os clientes de um projeto?
3. Explique o conceito de Stakeholder.
4. Explique o que é Escopo e sua im-
portância para a gestão do projeto.
5. Faça a montagem de roteiro para a 
elaboração de seu projeto.
COBRA, Marcos. Plano estratégico de ma-
rketing, 2ª edição. São Paulo.Atlas, 1989.
KOTLER, Philip. Marketing para o século 
21. São Paulo. Futura, 1999.
MAXIMIANO, Antônio Cesar Amaru. 
Administração de projetos. 4ª. Edição. São 
Paulo. Atlas, 2010.
OLIVEIRA, Djalma Pinto Rebouças. Pla-
nejamento estratégico. 5ª. Edição. São Pau-
lo. Atlas, 1991.
ROCCATO, Pedro Luiz. A bíblia dos ca-
nais de venda e distribuição. São Paulo. M. 
Books do Brasil, 2008.
SABBAG, Paulo Yagisi. Gerenciamento de 
projetos e empreendedorismo. São Paulo. 
Saraiva, 2013.
Referências
52
SHENHAR, Aaron et DVIR, Dov. Rei-
ventando o gerenciamento de projetos. São 
Paulo. M. Books do Brasil, 2010.
SAMSÃO, Woiler. Projetos: planejamento, 
elaboração, análise. São Paulo. Atlas, 1996.
53