AVALIAÇÃO DE CRONOGRAMAS EM PROJETOS …abepro.org.br/biblioteca/TN_STO_206_221_27947.pdf ·...

AVALIAÇÃO DE CRONOGRAMAS EM

PROJETOS COMPLEXOS: ESTUDO DE CASO EM

UM PROJETO

Pedro Arthur Faria de Souza (UFF)

[email protected]

Sandro Alberto Vianna Lordelo (UFF)

[email protected]

SARA MONALIZA SOUSA NOGUEIRA (UFRJ)

[email protected]

Jose Rodrigues de Farias Filho (UFF)

[email protected]; [email protected]

Este estudo tem como objetivo analisar as principais práticas sobre a

elaboração e o controle de cronogramas em projetos complexos. Será

analisado cada componente de um cronograma, buscando mostrar como ele

deve ser utilizado e quais os impactos eu o seu uso inapropriado possui. Será

feito ainda um estudo de caso em um projeto real “EPC” de conversão de

uma plataforma, com o intuito de realizar um diagnóstico de seu cronograma

por meio do software Acumen Fuse®. Esta avaliação será feita com base nas

práticas discutidas ao longo do presente estudo, onde cada indicador de

desempenho terá um critério de avaliação para que o cronograma seja lógico

e consistente. Serão discutidos ao final os impactos dos desvios dos critérios,

assim como proposição de planos de ação para tornar o cronograma mais

eficiente.

Palavras-chave: Gerenciamento de projetos, escopo, cronograma,

indicadores, diagnóstico, EPC, engenharia, suprimentos, construção, offshore,

construção naval

XXXV ENCONTRO NACIONAL DE ENGENHARIA DE PRODUCAO

Perspectivas Globais para a Engenharia de Produção

Fortaleza, CE, Brasil, 13 a 16 de outubro de 2015.




2

1. Introdução

Projetos de construção naval para o mercado offshore podem ser caracterizados como sendo

do tipo EPC (do inglês, Engineering, Procurement and Construction). Neste caso, a

contratante designa a uma empresa (denominada de “Epecista”) a responsabilidade de realizar

a engenharia do projeto, a contratação de toda a matéria prima necessária e a construção em

si.

Os projetos do tipo EPC são caracterizados pelo grande volume de investimento do

contratante, longa duração e complexidade técnica e gerencial (FARIAS FILHO, 2010).

Assim, o gerenciamento de um projeto deste porte torna-se cada vez mais difícil, e controlar

todas as variáveis envolvidas nele, como cronograma, escopo, custo, qualidade, comunicação

e outras, é uma tarefa crítica para as empresas “Epecistas”.

De acordo com o PMI (2009), projetos, em geral, são empreendimentos complexos e que

necessitam de um plano para guiar sua execução. Portanto, é imperativo ao projeto a

existência de um cronograma que irá controlar os prazos, os recursos, as entregas e a evolução

do projeto, gerenciado por uma equipe capacitada.

O presente trabalho teve como escopo, a análise de um questionário elaborado sobre a

consistência de cronogramas em projetos de alta complexidade, neste caso, em um estudo de

caso de um projeto de conversão de uma plataforma dentro do setor Offshore. E ainda,

objetivou-se a introdução de conceitos como o GASP (Generally Accepted Scheduling

Practices) e manuais do PMI (Project Management Institute) no intuito de mostrar a

contribuição de cada um deles para o Planejamento e Controle de projetos através de

Cronogramas lógicos e consistentes. Além disso, foi analisado um modelo já existente, o “14

Point Assessment” do Defense Contracts Management Agency (DCMA, 2011).

2. Revisão da literatura

Segundo o PMBOK (2008), o gerenciamento de projetos “é a aplicação de conhecimentos,

habilidade, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos”; e




3

um processo consiste de “um conjunto de ações e atividades inter-relacionadas, que são

executas para alcançar um produto, resultado ou serviço predefinido”.

Ainda de acordo com o PMBOK (op. cit.), os projetos estão divididos em cinco grupos de

processos: iniciação, planejamento, execução, monitoramento e controle, e encerramento.

Na fase de planejamento, a elaboração de um cronograma compreende uma atividade

fundamental para o sucesso do mesmo. O PMI (2007) cita que um cronograma “providencia

um mapa de rotas que representa como e quando o projeto irá entregar os produtos definidos

em seu escopo e pelo tempo do projeto"; este ainda, "suporta o projeto em organizar o seu

capital nas datas requeridas, a mobilização de recursos de uma maneira mais eficiente em

custo e economia dos gastos, em estabelecer coordenação entre os projetos, na detecção

antecipada dos problemas, onde as ações necessárias possam ser implementadas para atingir

os objetivos do projeto como foi planejado”.

É primordial que o cronograma seja elaborado e controlado de maneira correta, de forma que

retrate fielmente o que ocorre no projeto em termos de escopo, tempo, custo, etc. A primeira

etapa para o desenvolvimento de um cronograma de um projeto é definir sua estrutura e

decomposição.

Neste sentido surge o conceito de Estrutura Analítica de Projeto (EAP), que segundo o PMI

(2008), representa uma “decomposição hierárquica orientada às entregas do trabalho a ser

executada pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas,

sendo que cada nível descendente da EAP representa uma definição gradualmente mais

detalhada da definição do trabalho do projeto”.

Para o sucesso de um projeto, além de uma EAP bem estruturada, é necessário, segundo o

GAO (2012), “um cronograma integrado e confiável que defina quando e por quanto tempo o

trabalho irá acontecer e como uma atividade se relaciona com a outra”. Para este autor, as

melhores práticas a obtenção de um cronograma de alto nível de qualidade e confiabilidade

são: capturar todas as atividades (regra dos 100%); sequenciá-las; atribuir recursos para estas

(mão de obra, material, despesas gerais, etc.); estabelecer uma duração real para essas;

verificar se o cronograma pode ser traçado horizontalmente e verticalmente; confirmar se o

caminho crítico é valido; garantir uma folga total razoável; conduzir uma análise de risco no




4

cronograma; atualizar o cronograma utilizando o progresso atual e lógica; e manter um

cronograma como linha de base.

3. Metodologia

Realizou-se um estudo de caso em uma empresa EPCista que possui um esquema de

responsabilidade do projeto conforme a figura 1 abaixo:

Figura 1: Esquema de responsabilidades do projeto – Estudo de Caso

Fonte: Elaborado pelo autor

O gerenciamento do cronograma foi feito pela equipe de Planejamento. Esta equipe estava

subdividida em duas, sendo uma responsável pelo cronograma de Engenharia e Suprimentos e

outra pelo de Construção e Montagem.

Dividiu-se a avaliação do cronograma em duas fases. Primeiramente foi aplicado um

questionário aos integrantes da equipe de Planejamento do Epecista, responsáveis por gerir o

cronograma do projeto. A outra fase será a aplicação de um modelo de diagnóstico do




5

cronograma por meio de um software especializado.

Foi escolhido o programa SurveyMonkey®, no processo de elaboração do referente

questionário, devido à sua facilidade de manuseio e à geração de resultados instantâneos e de

boa qualidade.

Para a melhor caracterização dos dados, a pesquisa foi direcionada aos profissionais

responsáveis pelo planejamento e controle do cronograma abordado no Estudo de Caso: dois

engenheiros de planejamento, dois técnicos de planejamento e um coordenador de

planejamento. A resposta destes serviu de base para cruzar os dados obtidos no diagnóstico,

além dos problemas observados em projetos do tipo EPC (PM SURVEY, 2012).

A fim de verificar a aderência do cronograma às boas práticas apresentadas, foram realizadas

análises das diversas características desse cronograma, utilizando como ferramenta auxiliar o

software Acumen Fuse®, que facilita a geração dos resultados e proporciona um diagnóstico

detalhado. O Fuse permite que seja importado à sua base de dados um cronograma do

Primavera P6®, e atribuído à este um outro cronograma como Linha de Base.

Foram selecionados o cronograma atual do projeto, denominado de Corrente, e outro que

serviu de modelo para o cumprimento dos prazos, denominado de Linha de Base. O progresso

das atividades tem a característica de “Lógica Retida”, onde mesmo que se um sucessor seja

finalizado antes de seu predecessor, a lógica do relacionamento permaneceu para o resto da

rede.

O diagnóstico foi todo realizado em cima das informações do cronograma Corrente. A Linha

de Base serviu apenas para a análise de um ponto de avaliação presente no Acumen Fuse® e

que foi utilizado neste diagnóstico.

Dividiu-se o diagnóstico em diferentes pontos de avaliação, ou seja, um conjunto de

indicadores em comum que juntos destacariam a qualidade do cronograma em determinado

ponto. Os pontos de avaliação em cronogramas avaliados foram: lógica, durações, aderência à

linha de base e caminho crítico. E cada ponto de avaliação conteve diversos indicadores, que

caracterizam uma medida quantitativa do grau que um sistema, componente, ou processo

possui de um dado atributo referente à um critério.




6

Para cada indicador foi definido um critério de avaliação, de modo a determinar a aderência

da mesma com as boas práticas de gerenciamento estudadas. Os resultados finais foram

gerados de modo a avaliar o quanto que a aderência ou não de cada indicador contribuiu para

a eficácia ou ineficácia de um bom gerenciamento do projeto.

4. Resultados e discussões

A seguir serão mostrados os valores obtidos para cada indicador estudado, classificando-se

em verde aqueles que atenderam ao critério de avaliação e em vermelho aqueles que não

atenderam.

Para os indicadores que de alguma forma estavam fora do limite estabelecido ou do valor

ideal estipulado, foi feita uma análise mais profunda das principais razões deste desvio.

Também foram apresentados os impactos que este desvio acarreta no cronograma e no

gerenciamento do projeto EPC.

Assim, conhecendo-se os impactos gerados, poderão ser criados planos de ação com o

objetivo de melhorar a avaliação deste indicador no sentido de que o mesmo passe a respeitar

os critérios previamente estabelecidos.

4.1. Lógica

Na avaliação da lógica do cronograma, 8 dos 15 indicadores não atenderam aos critérios

estabelecidos (Tabela 2).

Tabela 2: Resultados do diagnóstico - Lógica

Lógica

Código Indicador Valor

I-1.1 Falta de Predecessores 4

I-1.2 Falta de Sucessores 9

I-1.3 Percentual de Relacionamentos I-I 3%

I-1.4 Percentual de Relacionamentos I-T 0%

I-1.5 Percentual de Relacionamentos T-T 15%

I-1.6 Percentual de Relacionamentos T-I 82%

I-1.7 Densidade Lógica 4,24

I-1.8 Tendência de convergência 6%

I-1.9 Tendência de divergência 13%




7

I-1.10 Tendência lógica 2%

I-1.11 Início Aberto 7%

I-1.12 Término aberto 1%

I-1.13 Redundância 15%

I-1.14 Lógica Circular 0

I-1.15 Fora de sequência 3%

Fonte: Acumen Fuse® - Adaptado pelo Autor

Os indicadores I-1.1 e I-1.2 mostram que além dos marcos de início e fim do projeto, outras

atividades tiveram uma “quebra” de lógica em seus relacionamentos. Isto se mostra como um

fato isolado, uma vez que o próprio Contratante não permite que atividades fiquem sem

relacionamentos e, antes de entregar o cronograma mensalmente ao Contratante, estas

verificações são realizadas.

Como o teste foi feito com uma “foto” do cronograma em determinado momento,

possivelmente devido à algum trabalho de atualização mensal do cronograma estas atividades

perderam predecessores e sucessores. Foi acordado que estes desvios não possuem impactos

no projeto e que a equipe do projeto está alinhada com esse indicador.

Os indicadores I-1.5 e I-1.6 possuem forte relação entre si, já que o excesso de relações T-T

faz com que o percentual de relacionamentos T-I fique abaixo do previsto. Isto se mostra

como uma estratégia da rede de atividades para aceleração do projeto, fazendo com que

atividades ocorram concomitantemente e terminem num mesmo momento. Foram levantados

os principais casos de relacionamentos T-T, que são:

a) Fabricação – Testes: A fabricação dos equipamentos comprados para a plataforma

terminam no mesmo momento em que o último teste é realizado no fornecedor.

b) Certificação de Documentos de fornecedor – Apresentação da certificação emitida e

aprovada: Esta ligação envolve os cronogramas de Engenharia e Suprimentos, e

significa que a atividade de apresentação da certificação dos documentos certificados

de um pacote de equipamentos se encerra junto com a certificação do último

documento.

c) Modelagem 3D – Emissão de documento de projeto: Neste relacionamento os

documentos de Engenharia são emitidos assim que se termina de modelar uma área da

plataforma.




8

d) Marco de informação de Suprimentos – Emissão de documento de projeto: Neste caso

o marco de informação significa algum dado que a Engenharia precisa de um

fornecedor para emitir um documento, e assim que este é recebido a Engenharia

consegue emitir o documento do projeto.

Por meio da análise destes relacionamentos e de abordagens com a equipe de Planejamento,

conclui-se que a quantidade teoricamente excedente de relacionamentos T-T reflete a

realidade do projeto e a maneira como as atividades ocorrem.

A densidade lógica (I-7) também ultrapassou o limite estabelecido (4,24 contra 4), porém ao

se analisar quais eram as atividades que contribuíam para esse valor, foi notado que 2

atividades (marco de fim da Engenharia e de fim do projeto) tinham uma quantidade de

relacionamentos muito acima das outras. O marco de fim da Engenharia possuía 3486

relacionamentos e o de fim do projeto outros 1558.

O teste foi realizado novamente ocultando-se essas duas atividades, e o valor encontrado para

a Densidade Lógica foi de 3,96, que estaria dentro dos padrões estabelecidos pelo software.

Conclui-se que o desvio da Densidade Lógica não possuía impacto dentro do cronograma,

uma vez que os relacionamentos estabelecidos com as duas atividades destoantes eram

coerentes.

O cronograma evidenciou também uma Tendência de Divergência (I-1.9), ou seja, um grande

número de atividades com mais de dois sucessores. A análise destas atividades mostrou que

cerca de metade delas com estas características faziam parte do fluxo de documentos da

Engenharia, especialmente da 1ª emissão dos documentos. Esta atividade precede outras, tais

como:

a) Recebimento de comentários do Contratante

b) Recebimento de comentários da Sociedade Classificadora

c) Fim da Engenharia Básica ou de Detalhamento

d) Outros documentos de projeto

e) Delineamento dos desenhos (Construção e Montagem)

f) Modelagem em 3 Dimensões




9

Considerando os relacionamentos acima, sugere-se a troca da precedência do delineamento

dos de projeto da primeira revisão para a revisão Aprovada para Construção dos documentos.

Esta ligação ocorreu devido à uma estratégia de “Fast Tracking” (aceleração das atividades

fazendo programando atividades para serem executadas em paralelo), onde assumiu-se os

riscos de relacionar as atividades de fabricação com a primeira revisão dos documentos de

Engenharia, sem esta passar pelo fluxo de comentários e estar aprovada para a construção.

Sugere-se a quebra dos relacionamentos com a modelagem 3D. Conforme o andamento do

projeto, notou-se que essa rede de precedência não vinha sendo respeitada, o que invalidava o

relacionamento e aumentava ainda o valor do indicador I-1.15 (Fora de Sequência). Outra

solução para alguns casos é a quebra dos relacionamentos com o fim do projeto básico ou de

detalhamento, visto que estas ligações são redundantes.

Foram feitas abordagens à equipe do projeto para se entender o porquê o indicador I-1.11

(Início Aberto) ter excedido o seu limite. As respostas obtidas foram de um desconhecimento

deste grande nº de atividades pendentes, tanto por parte do Epecista quanto pelo Contratante,

que não avalia este tipo de erro no cronograma e nunca solicitou uma correção.

Segundo o GAO (2012) “atividades pendentes podem prejudicar a programação de uma

atividade”. Sugere-se a avaliação destas atividades para a posterior conexão do início destas

atividades com seus devidos predecessores. Isto ajudaria na previsão da duração das

atividades e a sinalizar possíveis atrasos nas atividades.

O indicador I-1.13 mostrou que grande parte dos relacionamentos presentes no cronograma

são de fato desnecessários. A redundância se deve à complexidade do cronograma, que por

vezes faz com que por desatenção da equipe de planejamento crie relacionamento deste tipo.

O principal impacto deste desvio é aumento da complexidade e do tamanho do cronograma

sem necessidade, tornando-o mais difícil de manusear e gerenciar. Foi sugerido que esses

relacionamentos fossem excluídos, uma vez que não impactariam no resto do projeto.

4.2. Durações

Na avaliação relativa às durações de cada atividade do cronograma, dois dos quatro

indicadores não atenderam o critério estabelecido (Tabela 3).




10

Tabela 3: Resultados do diagnóstico - Durações

Durações


I-2.1 Excedente do cronograma 4%

I-2.2 Detalhamento insuficiente 1%

I-2.3 Razão entre marcos e tarefas 26%

I-2.4 Duração inválida 3%


O indicador I-2.3 mostra um número excessivo de marcos no cronograma em relação ao

número de tarefas. A grande maioria dos marcos se localiza no cronograma de Engenharia,

numa subdivisão de atividades sem peso. Como destacado antes, foram criados marcos no

cronograma sem peso financeiro para ser alocado no fluxo dos documentos do projeto.

Alguns dos exemplos são:

a) Recebimento de proposta do fornecedor

b) Recebimento de comentários do Contratante

c) Recebimento de aprovação do Contratante

d) Recebimento de comentários da Sociedade Classificadora

e) Recebimento de aprovação da Sociedade Classificadora

f) Aprovação do Parecer Técnico da proposta do fornecedor

g) Recebimento de documento do fornecedor

Segundo abordagens realizadas à equipe de Planejamento, a criação destes marcos no

cronograma possui um efeito muito positivo, uma vez que permitem um controle detalhado do

fluxo de documentação do projeto no Primavera. Todavia, foi relatado que a Projetista,

responsável pelo cronograma, não controla estes marcos de forma correta, dificultando a

atualização mensal do Primavera pelo Epecista. Mensalmente são realizadas avaliações nestes

marcos, onde se percebe um grande número de atividades sucessoras destes já realizadas

enquanto os marcos não tiveram seu progresso informado.

Quanto às tarefas com zero dias de duração (I-2.4), foi necessário abordar à equipe do projeto

para entender os reais motivos desta característica. Para as atividades já realizadas, a




11

justificativa era a forma de que o progresso era inserido no Primavera. Neste caso, as datas de

início e fim das atividades que foram informadas ao sistema eram iguais, o que fazia com que

a atividade não tivesse duração quando era exportada ao cronograma.

Para as atividades em andamento ou ainda não realizadas, a equipe do projeto não soube

responder os reais motivos e reconheceu que isto reflete uma situação irreal e que deve ser

corrigida.

Para ambos os casos sugere-se a correção destas durações. Para as atividades realizadas,

objetiva-se o registro da duração real do projeto para manter a gestão de conhecimento para

projetos futuros. Para as atividades que ainda serão executadas, busca-se representar a

duração real em que a atividade irá acontecer.

4.3 Aderência à Linha de Base

Conforme mostrado anteriormente, os indicadores que comparavam o cronograma corrente

com à Linha de Base não toleravam desvios, uma vez que não seria possível estipular um

valor aceitável para falhas relativas à um planejamento previamente executado. Com isso,

nenhum indicador deste ponto conseguiu atingir perfeitamente a linha de base e foram

classificados como não aderentes (Tabela 4).

Tabela 4: Resultados do diagnóstico –Aderência à Linha de Base

Aderência à Linha de Base


I-7.1 Desvio de atividades realizadas 6

I-7.2 Desvio de atividades planejadas 72

I-7.3 Desvio de durações 1

I-7.4 BEI (BaselineExecution Index) 0,63


Neste ponto de avaliação em particular,cada indicador mensura a quantidade de desvio, e não

se busca analisar se ele atendeu ou não ao critério, pois isto seria muito improvável devido às

circunstâncias dinâmicas existentes em um projeto deste porte.

No cálculo do desvio da programação das atividades, percebe-se uma discrepância muito




12

maior naquelas ainda não realizadas (I-7.2), mostrando que em média cada atividade do

cronograma está deslocada 72 dias a frente da sua Linha de Base. Apesar dos principais

marcos do projeto continuarem sendo respeitados e o projeto conter uma folga média elevada,

este deslocamento das atividades aumenta o risco de atrasos futuros do projeto.

Outro problema relacionado à este desvio é a constante mudança de prioridade e escopo,

conforme mostram as respostas dos questionários. Na Engenharia, por exemplo, a mudança de

priorização da fabricação de determinadas estruturas para a embarcação faz com que a ordem

da emissão dos desenhos mude drasticamente, acarretando num plano de execução diferente

da linha de base anteriormente salva.

Conforme conversado com a equipe do projeto, as principais causas para os atrasos da

Engenharia são:

a) Problemas de interface com os fornecedores

b) Indefinições de projeto entre Contratante, Epecista e Projetista

c) Inconsistência de algumas datas planejadas com o que a disciplina consegue emitir de

documentação

Apesar de no questionário a equipe do projeto destacar que as durações do cronograma não

correspondem à realidade de execução das atividades, o desvio das durações reais das

atividades realizadas e das durações que foram planejadas pela Linha de Base é de apenas 1

dia.

No cálculo do BEI no indicador I-7.4, o resultado de 0,63 mostra que o número de atividades

realizadas é bem menor do que as deveriam ter sido realizadas até a data de 24/10/2013, o que

um grande atraso no cronograma. Todavia, o fato da curva oficial do projeto ser físico-

financeira faz com que os atrasos dependam também do peso relativo a cada atividade, o que

faz com que o desvio “Planejado x Realizado” seja menor.

Utiliza-se o BEI para o controle físico de documentos de Engenharia no projeto. Porém, para

a análise do cronograma como um todo, este índice pode ser considerado muito “simples” e

com pouca possibilidade de aprofundamento. O DCMA (2011) afirma que “este índice não

considera deslocamentos no cronograma nem o uso permitido de folga nas atividades”.




13

4.4 Caminho Crítico

Na avaliação do caminho crítico do projeto, apenas 2 indicadores não atenderam os critérios

(Tabela 5).

Tabela 5: Resultados do diagnóstico – Caminho Crítico

Caminho Crítico


I-8.1 Folga total de atividades críticas 0

I-8.2 Atividades críticas de longa duração 6

I-8.3 Atividades críticas com esperas 7

I-8.4 Teste do caminho crítico (CPT)

I-8.5 CPLI (Critical Path Lenght Index) 1


A validação da existência do caminho crítico com o CPT e o fato de o CPLI ter o valor de 1

são consequência da folga das atividades críticas serem iguais a zero. Entretanto, os

indicadores que fizeram uma análise mais profunda quanto às atividades críticas (I-8.2 e I-8.3)

evidenciaram alguns problemas.

As durações elevadas são referentes a 4 atividades de Construção e 2 de Comissionamento.

Conforme já mencionado, o cronograma do comissionamento ainda não foi detalhado por

completo, fazendo com que algumas atividades tenham durações muito grandes,pois

compreendem um conjunto de atividades que ainda serão “quebradas” em outras.

Quanto às esperas no caminho crítico, foi notado que as maiores correspondem às ligações

entre as atividades finais de Comissionamento e a entrega da plataforma (marco de fim).

Grande parte do caminho crítico foi preenchida com esperas devido à falta de detalhamento

do Comissionamento e a necessidade de alocar o fim do projeto em determinada data. De

acordo com o GAO (2012) “a presença de esperas no caminho crítico ofuscam a identificação

e o gerenciamento das atividades críticas”

5. Conclusões

A realização do estudo de caso serviu para aplicar os conhecimentos destacados nos principais

manuais relativos ao tema em um contexto real, mostrando como são utilizados os

componentes de um cronograma e como eles são gerenciados pela equipe de Planejamento.




14

No estudo de caso, foram detectadas diversas situações onde o excesso de detalhamento

dificultava o controle das atividades sem agregar valor ao projeto, e outras em que a falta de

detalhamento criava atividades críticas de longa duração e com altos valores de esperas em

seus relacionamentos.

Notou-se ainda, que a inutilização de algumas atribuições do Primavera P6, como o uso de

recursos, gestão de risco, controle financeiro e utilização de verificações de consistência

prejudica o monitoramento das atividades do cronograma. Conforme mencionado, muitos

desses atributos estão em outros softwares e são geridos por departamentos diferentes.

Sugere-se que, senão utilizar todos os atributos em uma única ferramenta, haver uma interface

maior entre elas no intuito de ajudar a tomada de decisões e tornar o gerenciamento do projeto

mais eficaz.

O diagnóstico feito no estudo de caso conseguiu atingir os seus objetivos de analisar a

consistência do cronograma e propor melhorias para o mesmo no intuito de tornar o

gerenciamento do projeto mais eficaz. A leitura dos manuais, o questionário com a equipe do

projeto e os testes feitos pelo software proporcionaram diversas análises de onde conseguiu

ser percebida essas oportunidades de melhoria.

O grande desafio do estudo de caso foi a análise dos resultados do diagnóstico. Buscou-se

discutir apenas os indicadores não aderentes aos critérios, e foi necessária uma análise mais

profunda do cronograma para analisar estes desvios, indicando suas causas e impactos e

propondo soluções de melhoria.O extrato fornecido pelo software de cada ponto de avaliação

proporcionou o detalhamento dos resultados e facilitou as análises.

Notou-se que os desvios de muitos indicadores não significavam uma falha do cronograma,

mas sim refletia a realidade da rede de atividades do projeto e a forma com que ela acontece

de fato. Isto ratifica a necessidade do aprofundamento dos resultados antes de “julgar” o

cronograma do projeto apenas pela aderência ou não ao critério estabelecido.

6. Referências

ACUMEN FUSE. ACUMEN SOFTWARE. April 2013 Edition. User Guide v4.1.5

DCMA – EUA. DEFENCE CONTRACT MANAGEMENT AGENCY (DCMA) 14-POINT ASSESSMENT,




15

2011

FARIAS FILHO, J.R. ; BAHIA, FABIO . Análise de Critérios de Sucesso em Projetos de Engenharia,

Suprimentos e Construção (EPC) - XXX Encontro Nacional e Engenharia e Produção, 2010

GAO – EUA. United States Government Accountability Office – GAO SCHEDULE ASSESSMENT GUIDE,

2012

PASEG – EUA. NDIA ICPM Planning and Scheduling Excellence Guide, 2011

PMI. – Practice Standard for Scheduling – EUA: Project Management Institute, 2007

PMBOK. Um guia do conhecimento em Gerenciamento de Projetos. Guia PMBOK® 4ª. ed. – EUA: Project

Management Institute, 2008.

PMI 2009 ???

PMI 2008 ??? É o PMBOOK???

PMSURVEY. 2012 Edition. Project Management Institute Chapters

PMI. Practice Standard for Work Breakdown Structure. 2ª. ed. – EUA: Project Management Institute, 2006.

SINAVAL – Cenário do 4º Trimestre de 2012 – Balanço Anual – Dezembro 2012

SLACK, NIGEL – Administração da Produção / Nigel Slack, Stuarr Chambers, Robert Johnston. – 3 ed. – São

Paulo : Atlas, 2009

AVALIAÇÃO DE CRONOGRAMAS EM PROJETOS …abepro.org.br/biblioteca/TN_STO_206_221_27947.pdf ·...

Documents

Transcript of AVALIAÇÃO DE CRONOGRAMAS EM PROJETOS …abepro.org.br/biblioteca/TN_STO_206_221_27947.pdf ·...