AVALIAÇÃO DE CRONOGRAMAS EM PROJETOS COMPLEXOS: ESTUDO DE CASO EM UM PROJETO

AVALIAÇÃO DE CRONOGRAMAS EM PROJETOS COMPLEXOS: ESTUDO DE CASO EM UM PROJETO Pedro Arthur Faria de Souza (UFF) pedro.afs91@gmail.com Sandro Alberto Vianna Lordelo (UFF) sandrolordelo@gmail.com SARA MONALIZA SOUSA NOGUEIRA (UFRJ) saramsnogueira@gmail.com Jose Rodrigues de Farias Filho (UFF) rodrigues@labceo.uff.br; fariasfilho@gmail.com 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

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 2

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 3

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 4

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. 5

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% 6

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. 7

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 8

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). 9

Tabela 3: Resultados do diagnóstico - Durações Durações Código Indicador Valor 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% Fonte: Acumen Fuse - Adaptado pelo Autor 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 10

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 Código Indicador Valor 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 Fonte: Acumen Fuse - Adaptado pelo Autor 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 11

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ísicofinanceira 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. 12

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 Código Indicador Valor 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 Fonte: Acumen Fuse - Adaptado pelo Autor 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. 13

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, 14

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 15