_GERENCIAMENTO DE PROJETOS_ APLICAÇÃO DE SCRUM NA RETOMADA DE OBRA CIVIL INACABADA

Prévia do material em texto

ANELISE DIAS FOLHA OLIVEIRA 
 
 
 
 
 GERENCIAMENTO DE PROJETOS: APLICAÇÃO DE 
SCRUM NA RETOMADA DE OBRA CIVIL INACABADA 
 
 
Trabalho de Conclusão de Curso 
apresentado ao curso MBA em 
Gerenciamento de Projetos, de Pós-
Graduação lato sensu, Nível de 
Especialização, da FGV/IDE como pré-
requisito para a obtenção do título de 
Especialista. 
 
Orientador: Danielle Barbosa Paoliello 
 
Recife – PERNAMBUCO 
2020 
 
 
 
FUNDAÇÃO GETULIO VARGAS 
PROGRAMA FGV MANAGEMENT 
MBA EM GERENCIAMENTO DE PROJETOS 
 
 
O Trabalho de Conclusão de Curso 
Gerenciamento de Projetos: aplicação de scrum para retomada de obra civil 
inacabada. 
 
elaborado por Anelise Dias Folha Oliveira 
 
 
e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de 
Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de 
pós-graduação, nível de especialização do Programa FGV Management. 
 
 
Recife, 30 de agosto de 2020. 
 
 
André Barcaui 
Coordenador Acadêmico Executivo 
 
 
Danielle Barbosa Paoliello 
Orientador 
 
 
 
 
TERMO DE COMPROMISSO 
 
 
A aluna Anelise Dias Folha Oliveira, abaixo assinado, do curso de MBA em 
Gerenciamento de Projetos, Turma GP PJ29, do Programa FGV Management, 
realizado nas dependências da FGV Recife, no período de 24/8/2018 a 26/8/2020, 
declara que o conteúdo do Trabalho de Conclusão de Curso intitulado: 
Gerenciamento de Projetos - aplicação de scrum para retomada de obra civil 
inacabada é autêntico, original e de sua autoria exclusiva. 
 
 
Recife, 26 de agosto de 2020. 
 
 
Anelise Dias Folha Oliveira 
 
 
 
 
 
AGRADECIMENTOS 
 
Primeiramente agradeço a Deus por mais essa conquista na minha vida, pela 
energia, disposição e inteligência dados por Ele. 
Ao meu marido, Raphael Dias, que sempre me incentivou e suportou finais de 
semana cuidando dos nossos filhos para que eu realizasse esse curso. 
Aos meus pais, que são as pessoas que mais acreditam em mim e me incentivam 
nessa vida. Àqueles que se privaram de muito desde o meu nascimento em função 
do meu crescimento pessoal e profissional. 
Aos meus sogros, que com muita paciência e amor cuidaram dos meus filhos para 
que eu pudesse estudar e fazer este trabalho de conclusão de curso. 
Às minhas amigas Kalinka Sarafim, Carina Lopes, Gabriela Soares e Lais França, 
que me ajudaram, me ensinaram e debateram ideias comigo. Cada uma com seu 
contexto profissional tão diferente e mesmo assim conseguimos dialogar e ensinar 
umas às outras. 
 
 
 
RESUMO 
 
Os projetos de engenharia civil costumam adotar uma abordagem tradicional de 
gerenciamento. É comum que uma obra seja bem planejada, as plantas sejam bem 
definidas e o design arquitetônico seja previamente pensado. Desta forma, 
planejasse o custo e o prazo de uma obra. Todavia, é possível que por diversos 
motivos uma obra seja paralisada por um longo tempo e retomá-la exigem alguns 
desafios. O objetivo deste estudo é comparar os métodos tradicional e ágil e explicar 
porque o método de SCRUM pode ser uma ferramenta valiosa quando tratamos de 
uma obra que foi interrompida e posteriormente retomada. Ressalta-se que a 
metodologia aplicada para esse estudo é baseada em uma pesquisa bibliográfica de 
abordagem exploratória e qualitativa, dessa maneira, foi possível identificar as 
principais diferenças entre as práticas e explicar porque técnicas de gestão 
modernas podem ser utilizadas em projetos tradicionais que se encontram em 
situações ondem precisam fazer uso da inovação e flexibilidade. 
 
 
 
Palavras-Chave: Metodologia Ágil; SCRUM; Metodologia Tradicional de Projetos; 
Remanescente de Obra Civil. 
 
 
 
 
 
 
 
 
ABSTRACT 
 
Civil engineering projects often take a traditional approach to management. It is 
common for a work to be well planned, the plants to be well defined and the 
architectural design to be previously thought out. In this way, plan the cost and term 
of a work. However, it is possible that for a variety of reasons a work may be 
paralyzed for a long time and resuming it requires some challenges. The aim of this 
study is to compare the traditional and agile methods and to explain why the SCRUM 
method can be a valuable tool when dealing with a work that was interrupted and 
later resumed. It is noteworthy that the methodology applied for this study is based 
on a bibliographic research with an exploratory and qualitative approach, in this way 
it was possible to identify the main differences between the practices and explain 
why modern management techniques can be used in traditional projects that are 
found in situations where they need to make use of innovation and flexibility. 
 
 
Keywords: Agile Methodology; SCRUM; Traditional Project Methodology; Remnant 
Civil Work. 
 
 
 
 
 
 
 
LISTA DE ABREVIATURAS 
 
SM – SCRUM MASTER 
 
TD – TIME DE DESENVOLVIMENTO 
 
MVP – PRODUTO MÍNIMO VIÁVEL 
 
PMI – PROJECT MANAGEMENT INSTITUTE 
 
PMBOK® – PROJECT MANAGEMENT BODY OF KNOWLEDGE 
 
PMI – PROJECT MANAGEMENT INSTITUTE 
 
PO – PODUCT OWNER 
 
EAP – ESTRUTURA ANALÍTICA DE PROJETO 
 
 
 
 
LISTA DE FIGURAS, QUADROS E TABELAS 
 
Figura 1 – Diferenças entre Projetos e Processo ...................................................... 13 
Figura 2 - As áreas de conhecimento se relacionando em projeto se relacionando 
com a Tríade de Projetos .......................................................................................... 17 
Figura 3 - As dimensões de sucesso em projetos ..................................................... 19 
Figura 4 - O ciclo de vida do projeto subdividido em fases de processo ................... 20 
Figura 5 - As 10 áreas de conhecimento do gerenciamento de projetos .................. 21 
Figura 6 - Diversas abordagens ágeis ....................................................................... 26 
Figura 7 - Papeis, cerimónias e artefatos no Framework Scrum ............................... 27 
Figura 8 - Ciclo Scrum ............................................................................................... 29 
 
 
Quadro 1 - Benefício do Gerenciamento de Projeto .................................................. 16 
Quadro 2 - Quadro resumo/comparativo entre o gerenciamento tradicional e ágil ... 31 
 
 
Tabela 1 - Comparativo Métodos Ágeis e Tradicionais ............................................. 32 
 
 
 
 
 
 
SUMÁRIO 
 
1. INTRODUÇÃO 10 
2. FUNDAMENTAÇÃO TEÓRICA 12 
2.1 Conceitos e Definições 12 
2.1.1 Projetos 12 
2.1.2 Gerenciamento de Projetos 13 
2.1.3 Medida de Sucesso de um projeto 17 
2.1.4 Metodologia Tradicional de Gerenciamento de Projetos 19 
2.1.5 Método Ágil de Gerenciamento de Projetos 24 
3. METODOLOGIA TRADICIONAL VERSUS metodologia ágil (scrum) 30 
3.1 Ciclo de Planejamento 32 
3.2 Avaliação de Resultados 33 
3.3 Feedbacks 34 
4. RETOMADA DE OBRA PÚBLICA INACABADA 35 
4.1 Contexto Específico 36 
4.2 Metodologia Ágil aplicada na retomada de obra inacabada 38 
5. CONCLUSÃO 41 
REFERÊNCIAS BIBLIOGRÁFICAS 43 
 
 
 
 
10 
 
1. INTRODUÇÃO 
 
O mundo moderno, mutável, competitivo e globalizado, exige que as 
empresas estejam atentas as necessidades dos seus clientes e, por isso, o gestor 
precisa gerir projetos que entreguem valor agregado aos seus clientes e não 
simplesmente projetos que cumprem prazo, orçamento e escopo inicial. 
Quando um gerente de projetos se depara com a necessidade de gerir a 
execução de atividades interdependentes, executadas por diversas pessoas e que 
consomem recursos escassos, ele precisa escolher uma metodologia que o permita 
sincronizar tais atividades e manter o controle sobre o que será executado. Saber 
escolher qual metodologia utilizar na condução de um projeto é uma competência de 
extrema importância para um gestor de projetos e aumenta as suas chances de 
sucesso. A finalização do projeto precisa atender a necessidade do cliente e agregar 
valorao negócio da empresa. 
 
Em métodos tradicionais de gestão, entende-se que o produto só faz 
sentido quando é entregue em sua totalidade, ou seja, apenas com 100% 
do projeto cumprido é que o cliente perceberá algum valor. Por outro lado, 
métodos ágeis podem ser usados em projetos que permitem que um 
conjunto mínimo de funcionalidades já servirá para solucionar parte da 
necessidade do cliente e, ao ser entregue em parte, já representa uma 
diferença valorosa para ele (BUILDER, 2017 apud SAMPAIO, 2020). 
 
Não existe uma metodologia melhor que a outra. O que existe é uma 
metodologia mais adequada ao contexto de um projeto do que outra e, sendo assim, 
o gerente de projeto precisa conhecer as metodologias e saber analisá-las diante do 
contexto, para escolher a mais adequada. 
O objetivo deste trabalho é comparar as metodologias tradicional e ágil de 
gerenciamento de projetos, sob a ótica da necessidade de conclusão de uma obra 
que foi interrompida abruptamente, permanecendo parada por 3 anos, e depois 
precisou ser retomada. A proposta é que a partir da análise do contexto desta obra, 
seja possível observar a metodologia escolhida no cenário anterior e posterior a 
interrupção da obra civil da empresa ABC. 
 
11 
 
O presente trabalho é produto de uma revisão bibliográfica de monografias, 
artigos, livros e sites com o objetivo de, a partir de uma comparação entre 
metodologias tradicionais e metodologia de ágil (Scrum), evidenciar a possibilidade 
de utilização das duas metodologias em um projeto de construção civil, motivada por 
avaliação gerencial, diante de uma mudança ocorrida no cenário inicial da obra. 
A pesquisa realizada para desenvolvimento dessa monografia tem uma 
abordagem exploratória com o objetivo de trazer maior familiaridade, descrição e 
entendimento das particularidades de ambas as metodologias ágil (Scrum) e 
tradicional. Este documento foi embasado amplamente pela pesquisa de diversos 
estudiosos e pesquisadores. 
Usou-se como método, também, as informações citadas por Dias (2018 apud 
SAMPAIO, 2020): Para que um trabalho possa ser reconhecido como científico, 
precisa ser lógico, sistemático, coerente e bem argumentado. Isso o diferencia de 
outros conhecimentos como senso comum, sabedoria ou ideologia. 
Para a conclusão, discorrer-se-á sobre a possibilidade de utilização de 
metodologia ágil, com foco em SCRUM, como ferramenta de gestão para a 
conclusão de obra civil interrompida cuja primeira etapa da obra foi gerida sob 
métodos de gestão do PMI. 
A fundamentação teoria consistirá na exposição ampla de conceitos com 
relação a projetos, gerenciamento de projeto, conceitos de sucesso, metodologia 
tradicional e metodologia ágil, com foco em Framework Scrum. 
Apoiado nesse estudo ter-se-á o embasamento necessário para apontar 
porque o SCRUM, ferramenta ágil, pode ser utilizado para retomada de obra civil 
que foi interrompida sem planejamento de parada. 
 
 
 
 
 
 
 
 
 
 
12 
 
2. FUNDAMENTAÇÃO TEÓRICA 
 
Neste capítulo serão abordados, através do referencial teórico, os conceitos e 
fundamentos que enquadram um grupo de ação como um projeto, além disto serão 
abordados os referenciais de projetos clássicos e modernos. 
 
2.1 Conceitos e Definições 
 
2.1.1 Projetos 
 
De acordo com o PMBOK (PMI, 2017), projeto é um esforço temporário 
empreendido para criar um produto, serviço ou resultado único. 
Um projeto pode ser considerado como sendo quaisquer séries de atividades 
e tarefas que (i) possuem um objetivo específico se ser atingido dentro de 
determinadas especificações, (ii) possuem data de início de término definidas, (iii) 
possuem limite de financiamentos, (iv) consomem recursos humanos e não 
humanos e (v) são multifuncionais (ROWE, SANDRA F. 2020.p5). 
A característica de ser um produto ou serviço único é muito marcante para 
enquadramento de um grupo de tarefas e interações como projetos. Produtos e 
serviços repetidamente produzidos são classificados como processos, conforme 
demonstra a figura 1, pois dão origem a um resultado que já existiu no passado. 
Os projetos podem ser pequenos ou grandes, possuir baixa ou alta 
complexidade de interações, todavia nunca são contínuos, pois possuem um prazo 
determinado para início e fim, consomem recursos que serão transformados um 
produto ou serviço exclusivo. 
O resultado de um projeto pode até ser contínuo, mas o projeto não. Como 
por exemplo, a instalação de uma linha de produção de pasta de dente: o projeto 
consiste no planejamento, execução, monitoramento e controle dos equipamentos e 
infraestrutura de produção, todavia quando a unidade estiver ativa e produzindo, o 
projeto terá sido finalizado, dando início a uma gestão do processo de produção da 
pasta de dente. 
 
 
13 
 
Figura 1 – Diferenças entre Projetos e Processo 
 
Fonte: Página do site da Lamb Construções e Engenharia1 
 
2.1.2 Gerenciamento de Projetos 
 
Segundo o PMI (2017), gerenciamento de projetos é a aplicação de 
conhecimentos, habilidades, ferramentas e técnicas as atividades do projeto a fim de 
cumprir os seus requisitos. 
Um projeto que deseja êxito em sua execução, precisa ser bem gerenciado, 
ou seja, passar pelas etapas de planejamento, execução, monitoramento e controle, 
e por fim, não menos importante, pela fase de encerramento. Segundo Koontz e 
O’Donnel [1980 apud TORREÃO 2005], “gerenciar consiste em executar atividades 
e tarefas que têm como propósito planejar e controlar atividades de outras pessoas 
para atingir objetivos que não podem ser alcançados caso as pessoas atuem por 
conta própria, sem o esforço sincronizado dos subordinados”. 
Realizar o gerenciamento de projetos traz benefícios tangíveis à organização, 
como a redução da necessidade de reportes, definição clara de prazos e 
responsabilidades, medição da relação planejado X realizado, identificação 
antecipada de problemas, melhor realocação dos recursos e capacidade para avaliar 
se os objetivos não serão alcançados ou excedidos (HAROLD, 2015). 
 
1 Disponível em https://www.lamb.eng.br/gestao-de-projetos-x-gestao-de-processos-qual-a-diferenca/. 
Acesso em 27/07/2020. 
 
14 
 
A humanidade utiliza práticas de gerenciamento de projetos há muitos anos. 
Os egípcios construíram pirâmides e canais hidráulicos com complexidade incrível 
(VINCENTINO, 1997). Todavia o termo gerenciamento de projetos começou a ser 
utilizado, registrado e estudado a partir de 1945 com o advindo da 2ª guerra mundial. 
(HAROLD, 2015). 
Ao final de 1950 e início de 1960, a indústria aeroespacial e de defesa estava 
utilizando gerenciamento de projetos na maioria dos projetos e forçando os seus 
fornecedores para que utilizassem também. Em virtude da complexidade dos 
projetos e das interações, o governo estabeleceu um modelo de planejamento, de 
ciclo de vida e um sistema de monitoramento e controle. Além disso, criou um grupo 
de auditores para garantir que o dinheiro público fosse gasto conforme o planejado. 
Inicialmente, o setor privado tratou tais ações do governo como excesso de 
burocracia e não viu valor prático na gestão de projetos naquele momento 
(HAROLD, 2015). 
No auge dos projetos espaciais da NASA, em 1969, na Pensilvânia – EUA, 
aconteceu uma reunião entre 5 profissionais de gestão de projetos para discutir 
melhores práticas e o Jim Synder fundou o Project Management Institute – PMI. 
Registra-se que, atualmente, o PMI é a maior instituição disseminadora de 
conhecimento sobre gerenciamento de projetos, dedicada ao aprimoramento da 
gestão profissional de projetos (PMI, 2004 apud TOREÃO, 2005). 
O crescimento da gestão formal de projeto foi lento ao longo dos anos 70 e 
80. Em 1970, surgiram os primeiros impressos sobre o tema Gerenciamento de 
Projetos, todavia, muitas empresas não conseguiam visualizar claramente os 
benefícios, enquanto que o aumento da burocraciapodia facilmente ser percebido. 
As empresas tinham a ideia de que para implementar o Gerenciamento de Projetos 
seria necessária uma mudança revolucionária e essa “reestruturação” muitas vezes 
não era bem vista. Em geral, as empresas que adotavam esta metodologia de 
gestão normalmente eram empresas que tinham alto capital envolvido no projeto ou 
cujos projetos envolviam muitas complexidades (HAROLD, 2015). 
Conforme a gestão de projetos ia crescendo, alguns fatores se destacavam 
em uma implantação bem-sucedida, como por exemplo o papel do gerente. Ele se 
tornou o ponto central com uma responsabilidade integrativa (LAWRENCE; LORSH, 
1967). 
 
15 
 
A partir de 1990, com a crescimento da globalização, aumento da 
concorrência de mercado e surgimento de tecnologias, as empresas começaram a 
perceber o Gerenciamento de Projetos não mais como uma opção, mas como uma 
necessidade. As empresas precisavam ganhar flexibilidade e reduzir custos, melhor 
alocando suas equipes e recursos (HAROLD, 2015). 
Além da visão metodológica proposta pelo PMI, surgiram outras visões sobre 
formas de se gerenciar um projeto e uma delas foi a Scrum, que, segundo o Scrum 
Guide (2013), tem por objetivo definir um processo de desenvolvimento interativo e 
incremental do projeto. Em 1995, Ken Schwaber e Jeff Shutherland apresentaram 
pela primeira vez o Scrum na conferência de OOPSLA – Object Oriented 
Programming, Systems, Languages, and Applications. Nesta apresentação, Ken e 
Jeff expuseram o aprendizado que obtiveram ao longo de anos de aplicação do 
Scrum (BISSI, 2007). 
Em 1996, foi publicada pelo Project Management Institute (PMI) a primeira 
edição do Guia do PMBOK (Projetc Management Body of Knowledge) e este se 
tornou o pilar básico para a gestão e direção de projetos (PMI 2017). 
A quadro 1 mostra a mudança que ocorreu com relação a percepção dos 
benefícios pelas empresas: 
 
 
 
 
 
 
 
 
 
16 
 
Quadro 1 - Benefício do Gerenciamento de Projeto 
 
Fonte: HAROLD, 2015, p 55. 
 
No início dos anos 2000, já se observam mudanças econômicas e 
tecnológicas relevantes. As fusões e aquisições criavam empresas multinacionais e 
o gerenciamento de projetos passa a ser enxergado como uma competência 
estratégica. Em 2006, já se podiam ver equipes virtuais e escritórios virtuais de 
projetos se tornando comum. Em 2010, nota-se que a realização de projetos mais 
complexos fez surgir partes interessadas adicionais e o gerenciamento de 
relacionamento com as partes interessadas se tornou primordial, surgindo também a 
 
17 
 
necessidade de se ter uma governança formada por um comitê e não apenas pelo 
patrocinador (HAROLD, 2015, p. 55). 
 
2.1.3 Medida de Sucesso de um projeto 
 
Verzuh (2000) descreve sucesso na gestão de projetos dividindo-o em três 
parâmetros, abaixo citados, remetendo a tríade de Prazo, Custos e Escopo da 
metodologia tradicional de gerenciamento de projetos. 
 
a) Dentro do prazo (cumprimento do cronograma) 
b) Dentro do Orçamento (cumprimento da estimativa de custo projetada) 
c) Alta Qualidade (resultado de acordo com os requisitos especificados) 
 
A Teoria da Tripla Restrição considera que os projetos possuem um trade off 
entre prazo, custo e qualidade/escopo, conforme demonstra a Figura 2, e os 
requisitos e interesses dos patrocinadores impõe tais restrições. É importante 
percebê-las no início do projeto, pois serão balizadores importantes para futuras 
decisões dos gestores (NORO, 2012 apud BARACT, 2016) 
 
Figura 2 - As áreas de conhecimento se relacionando em projeto se relacionando com a Tríade de 
Projetos 
 
Fonte: D’ Avila, 2015 apud BARACAT, 2016 
 
18 
 
A alteração de algum dos pilares impacta nos demais pilares. Por exemplo, se 
o prazo for aumentado, ele impactará possivelmente no custo, ou caso se deseje 
mexer no custo, possivelmente haverá impacto na qualidade (PMI, 2017). 
Nos primórdios, o sucesso de um projeto era medido por termos técnicos, ou 
seja, se o projeto fosse entregue dentro do prazo, dentro da estimativa de custo 
prevista, atendendo aos requisitos estipulados inicialmente ele seria considerado um 
sucesso. Todavia, recentemente, observa-se o surgimento do pensamento de que o 
sucesso de um projeto também deve ser medido considerando-se a entrega de valor 
para a organização. Segundo Borba (2015 apud SAMPAIO, 2020), um projeto deve 
atingir os objetivos de modo a resolver a problemática da empresa de modo eficiente 
(tempo, custo, qualidade e segurança, etc) e eficaz (objetivos atingidos). 
Harold (2015) afirma que “O gerenciamento de projetos não poder ser bem-
sucedido a menos que o gerente de projetos esteja disposto a empregar uma 
abordagem sistémica”. 
Em 2013, Shenhar e Dvir haviam proposto a existência de 4 dimensões para 
o sucesso de um projeto, conforme demonstra a figura 3. A primeira dimensão é a 
de eficiência do projeto que abrange o cumprimento do cronograma e da estimativa 
de custo. A segunda dimensão tem o foco no cliente e busca verificar se os 
resultados do projeto atenderam às expectativas deles e atenderam as suas reais 
necessidades. A terceira dimensão avalia se os impactos do projeto sobre o negócio 
da empresa agregaram valor e trouxeram ganhos reais para a organização. Por fim, 
a quarta e última dimensão avalia se os projetos trarão ganhos para o futuro da 
empresa. 
O PMI (2017) reconhece que, além dos critérios de eficiência, o sucesso de 
um projeto pode incluir critérios adicionais vinculados a estratégia organizacional e a 
entrega de resultados do negócio. 
 
19 
 
Figura 3 - As dimensões de sucesso em projetos 
 
Fonte: BARACAT, 2016 apud Shenhar e Dvir, 2013. 
 
2.1.4 Metodologia Tradicional de Gerenciamento de Projetos 
 
O conjunto de métodos mais fortemente disseminado hoje e que possui 
reconhecimento internacional é o descrito no Project Management Body of 
Knowledge – PMBOK. Segundo o PMBOK (PMI, 2017), o guia prove diretrizes e 
conceitos de gerenciamento de projetos, apresentando a aplicação do 
conhecimento, processos, habilidades, ferramentas e técnicas amplamente 
reconhecidas como boas práticas com impacto significativo no sucesso do projeto. 
O PMBOK buscou identificar e descrever as práticas de gerenciamento de 
projetos que são “geralmente aceitas”, pois entende-se na comunidade de gestores 
de projetos que as práticas do guia são aplicáveis a maioria dos projetos e por isso 
considerada a metodologia tradicional; todavia, a equipe de gerenciamento de 
projetos deve sempre avaliar o que é melhor para o seu projeto, devendo escolher a 
melhor metodologia para o caso específico (VARGAS, 2018). 
Segundo a metodologia tradicional, para facilitar o entendimento e a aplicação 
do gerenciamento do projeto, ele deve ser dividido em fases que constituem seu 
ciclo de vida [Dinsmore e Cavalieri 2003]. Segundo Vargas (2018), “o entendimento 
dessas fases permite ao time do projeto melhor controle do total dos recursos gastos 
para atingir as metas estabelecidas”. O Gerenciamento de Projetos do PMBOK 
envolve 5 fases, que são: Iniciação, Planejamento, Execução, Monitoramento e 
Controle e Encerramento do Projeto. (HAROLD, 2015, p. 21). 
A figura 4 apresenta graficamente a distribuição das fases ao longo do 
projeto. E cada fase defini quem deverá ser envolvido e quais trabalhos técnicos 
serão desenvolvidos. O PMBOK chama as fases de processos. 
 
20 
 
 
Figura 4 - O ciclo de vida do projeto subdividido em fases de processo 
 
 
Fonte: VARGAS, 2018. 
 
O processo de iniciação consiste na seleção do melhor projeto, identificação 
dos benefícios oriundos do projeto, elaboração do documento de autorização e 
designação do gerente de projeto (VARGAS, 2018). 
O processo de planejamento implica na definição dos requisitos de trabalho, 
definição da qualidade e quantidade de trabalho, definição dos recursos 
necessários, programação das atividades e avaliaçãode riscos envolvidos 
(VARGAS, 2018). 
A etapa de execução envolve negociação com os membros da equipe, 
definição da direção do trabalho e liderança. Além disso, envolve mobilização de 
recursos e gestão do relacionamento com clientes e fornecedores. A maior parte dos 
esforços e orçamentos são consumidos nesta fase (HAROLD, 2015). A fase de 
execução materializa as ações previstas na fase de iniciação e de planejamento, e 
se houverem ocorrido erros nas fases anteriores serão percebidos aqui. (VARGAS, 
2018). 
 O monitoramento e o controle do projeto são fundamentais para a gestão, 
pois permite o rastreamento do progresso e a comparação dos resultados 
planejados com os resultados previstos, de modo a proporcionar a análise de 
 
21 
 
variações e impactos suportando as decisões dos ajustes que se fizerem 
necessários (HAROLD, 2015). 
Por fim, tem-se a etapa de encerramento do projeto onde é verificado se o 
escopo do projeto foi totalmente concluído e feito o encerramento formal do contrato, 
encerramento financeiros dos números ordenados e o encerramento administrativo 
da documentação (HAROLD, 2015). 
Além das fases de um projeto, o PMBOK® Guide 6ª edição (PMI, 2017) é 
dividido em 10 áreas, conforme figura 5, e 49 processos. 
 
Figura 5 - As 10 áreas de conhecimento do gerenciamento de projetos 
 
Fonte: VARGAS, 2018. 
 
 
Segundo Vargas (2018), as áreas de conhecimento são Integração, Escopo, 
Cronograma, Custo, Qualidade, Recursos, Comunicação, Riscos, Aquisições e 
gerenciamento de Partes Interessadas. Cada uma dessas áreas possuem um grupo 
de processos a eles relacionados, conforme os itens abaixo: 
 
a) Gerenciamento de Integração: é a área que busca garantir boa coordenação 
entre as demais áreas para que o projeto como um todo seja beneficiado; 
i. Desenvolver o termo de abertura; 
ii. Desenvolver o plano de gerenciamento do projeto; 
 
22 
 
iii. Orientar e gerenciar o trabalho do projeto; 
iv. Gerenciar o conhecimento do projeto; 
v. Monitorar e Controlar o gerenciamento do projeto; 
vi. Realizar o controle integrado de mudanças; 
vii. Encerrar o projeto ou fase. 
b) Gerenciamento de Escopo: é a área que identifica os requisitos e processos 
do projeto, garantindo que serão cumpridos e que não haverá alterações sem 
que seja atendido o fluxo de alteração de projeto; 
i. Planejar o gerenciamento escopo; 
ii. Coletar os requisitos; 
iii. Definir o escopo; 
iv. Criar EAP; 
v. Validar o escopo; 
vi. Controlar o escopo. 
c) Gerenciamento de Cronograma: Área que busca distribuir as entregas e 
tarefas ao longo do tempo, definindo o prazo para entrega do projeto. Além, 
disso ela controla o projeto com o objetivo de que o prazo de entrega 
proposto seja atendido; 
i. Planejar o gerenciamento de cronograma; 
ii. Definir as atividades; 
iii. Sequenciar as atividades; 
iv. Estimar as durações das atividades; 
v. Desenvolver o cronograma; 
vi. Controlar o cronograma. 
d) Gerenciamento de Custos: Área que busca definir o custo do projeto e as 
formas de garantir que a estimativa de custo do projeto seja atendida; 
i. Planejar o gerenciamento de custo; 
ii. Estimar o custo; 
iii. Determinar o orçamento; 
iv. Controlar o custo. 
e) Gerenciamento de Qualidade: Área que controla os requisitos do projeto para 
garantir que os produtos e serviços entregues estão em conformidade com o 
que foi solicitado pelo Cliente; 
 
23 
 
i. Planejar o gerenciamento da qualidade; 
ii. Gerenciar da Qualidade; 
iii. Controlar a Qualidade. 
f) Gerenciamento das Partes Interessadas: Área que identifica os stakeholders 
e atua para que sejam avaliados e estrategicamente gerenciados; 
i. Identificar as partes interessadas; 
ii. Planejar o gerenciamento das partes interessadas; 
iii. Gerenciar o engajamento das partes interessadas; 
iv. Monitorar o engajamento das partes interessadas. 
g) Gerenciamento das Aquisições: Área que engloba os processos requeridos 
para a contratação de bens e serviços externos à organização; 
i. Planejar o gerenciamento de aquisições; 
ii. Conduzir as aquisições; 
iii. Controlar as aquisições. 
h) Gerenciamento dos Riscos: Área que busca identificar, avaliar, propor 
respostas e monitorar os riscos do projeto; 
i. Planejar o gerenciamento dos riscos; 
ii. Identificar os riscos; 
iii. Realizar a análise qualitativa dos riscos; 
iv. Realizar a análise quantitativa dos riscos; 
v. Planejar as respostas aos riscos; 
vi. Implementar respostas aos riscos; 
vii. Monitorar os riscos. 
i) Gerenciamento das Comunicações: Área que engloba os processos que 
visam garantir a obtenção, distribuição e armazenamento correto das 
informações; 
i. Planejar o gerenciamento das comunicações; 
ii. Gerenciar as comunicações; 
iii. Monitorar as comunicações. 
j) Gerenciamento dos Recursos: Área que busca maior efetividade na utilização 
dos recursos (materiais, equipamentos e pessoas). 
i. Adquirir recursos; 
ii. Desenvolver a equipe; 
 
24 
 
iii. Gerenciar a equipe; 
iv. Controlar os recursos. 
 
2.1.5 Método Ágil de Gerenciamento de Projetos 
 
Os métodos ágeis surgiram formalmente na década de 90, sempre com 
enfoque em obter um gerenciamento mais flexível, aderente às expectativas dos 
clientes e que provesse respostas rápidas às constantes mudanças de mercado 
(PRIKLADNICKI, 2014). 
Em 2001, um grupo de pensadores independentes publicou o que seria 
considerado o “Manifesto Ágil”, doze princípios que norteariam os métodos ágeis. 
a) Nossa maior prioridade é satisfazer o cliente através da entrega 
contínua e adiantada de software com valor agregado. 
b) Mudanças nos requisitos são bem-vindas, mesmo tardiamente no 
desenvolvimento. 
Processos ágeis tiram vantagem das mudanças visando vantagem 
competitiva para o cliente. 
c) Entregar frequentemente software funcionando, de poucas semanas a 
poucos meses, com preferência à menor escala de tempo. 
d) Pessoas de negócio e desenvolvedores devem trabalhar diariamente 
em conjunto por todo o projeto. 
e) Construa projetos em torno de indivíduos motivados. Dê a eles o 
ambiente e o suporte necessário e confie neles para fazer o trabalho. 
f) O método mais eficiente e eficaz de transmitir informações para e entre 
uma equipe de desenvolvimento é através de conversa face a face. 
g) Software funcionando é a medida primária de progresso. 
h) Os processos ágeis promovem desenvolvimento sustentável. Os 
patrocinadores, desenvolvedores e usuários devem ser capazes de 
manter um ritmo constante indefinidamente. 
i) Contínua atenção à excelência técnica e bom design aumenta a 
agilidade. 
j) Simplicidade, a arte de maximizar a quantidade de trabalho não 
realizado é essencial. 
k) As melhores arquiteturas, requisitos e designs emergem de equipes 
auto organizáveis. 
 
25 
 
l) Em intervalos regulares, a equipe reflete sobre como se tornar mais 
eficaz e então refina e ajusta seu comportamento de acordo. 
(PRIKLADNICKI, R. et al, 2001) 
De acordo com o manifesto ágil, além dos 12 princípios, a mentalidade ágil é 
guiada por 4 valores: 
a) Indivíduos e interação entre eles mais que processos e ferramentas; 
b) Software em funcionamento mais que documentação abrangente; 
c) Colaboração do cliente mais que negociação de contratos; 
d) Responder a mudanças mais que seguir um plano. (PRIKLADNICKI et 
al, 2001) 
De acordo com a Agile Guide (2017), a mentalidade ágil abrange uma série 
de métodos/práticas e frameworks, sendo assim qualquer tipo de abordagem que 
atenda a todos os valores e princípios do jeito “ágil” de pensar será agregada aos 
métodos ágeis, a exemplo da figura 6 abaixo. 
 
 
26 
 
Figura 6 - Diversas abordagens ágeis 
 
 
Fonte: AGILE GUIDE, 2017 
 
Registra-se, entretanto, que neste documento o foco do estudo se restrige a 
análise do SCRUM, que segundo o Scrum Guide (2013), é definido como “um 
framework dentro do qual pessoas podem tratar e resolver problemascomplexos e 
adaptativos, enquanto produtiva e criativamente entregam produtos com o mais alto 
valor possível”. 
 
Segundo SCHWABER e SUTHELAND (2013), a Teoria do Scrum é baseada 
nas teorias empíricas de controle de processo. O empirismo afirma que o 
conhecimento vem da experiência atrelado a tomada de decisão com base no que é 
conhecido. Além disso, o SCRUM utiliza uma abordagem interativa e incremental 
para aperfeiçoar a previsibilidade e o controle de riscos. A transparência, a inspeção 
e a adptação são pilares que apoiam o controle do processo empírico. 
De acordo com Sutherland (2016 apud GONÇALVES, 2018), o “Scrum 
baseia-se em um ciclo de inspeção e adaptação, sendo necessário revisar o que já 
fez e analisar como poderia continuar fazendo melhor e mais rápido, retirando 
possíveis impedimentos”. 
O Scrum é um framework estrutural utilizado para desenvolver produtos 
complexos desde 1990 e dentro desta estrutura é possível inserir processos e 
técnicas. Conforme demonstrado na figura 7, as regras do SCRUM envolvem 
 
27 
 
eventos, papeis e artefatos, sendo papel do time Scrum gerenciar as relações e 
interações entre eles (SCHWABER; SUTHELAND, 2013). 
 
Figura 7 - Papeis, cerimónias e artefatos no Framework Scrum 
 
Fonte: GONÇALVES, 2018 
 
Os papéis são os diferentes componentes do Time Scrum e estes são: 
Product Owner (Dono do Produto), Scrum Master e time de desenvolvimento. Um 
Time Scrum é auto-dirigível e eles escolhem a melhor forma de completar o seu 
trabalho. Eles são multifuncionais e possuem competência para realizar o trabalho. 
Os times são criados para aperfeiçoar a flexibilidade, a criatividade e a produtividade 
(SCHWABER; SUTHELAND, 2013). 
Um Time Scrum realiza entrega de produtos de forma interativa e incremental, 
ou seja, eles realizam entregas incrementais sobre um produto “pronto” inicial, que 
estará sendo aperfeiçoado ao longo do tempo a partir da retroinformação da 
experiência dos consumidores, assim, o cliente sempre terá um produto funcional 
disponível (SCHWABER; SUTHELAND, 2013). 
O Product Owner defini e prioriza as funcionalidades do produto, além de ser 
o responsável pelo aceite ou rejeição do produto (PRIKLADNICKI, 2014). 
Segundo o Scrum Guide, o Product Owner “é uma pessoa e não um comitê. 
O Product Owner pode representar o desejo de um comitê no Backlog do Produto, 
mas aqueles que quiserem uma alteração nas prioridades dos itens de Backlog 
devem convencer o Product Owner”. 
 
28 
 
Por sua vez, o Scrum Master desempenha um papel de guardião do 
framework, retirando os obstáculos para garantir o bom fluxo dos processos, a 
produtividade e a comunicação da equipe. (SCHWABER; SUTHELAND, 2013). 
O Time de Desenvolvimento são os responsáveis pela entrega dos requisitos 
a cada Sprint. Eles são auto organizados e multifuncionais. Os participantes são 
chamados de desenvolvedores, independente da sua formação acadêmica, 
habilidade ou papel no grupo. Um time possui todas as habilidades necessárias para 
criar o incremento do produto dele (SCHWABER; SUTHELAND, 2013). 
Segundo Bissi (2007), o SCRUM possui 3 fases (cerimônias) que se dividem 
entre planejamento, desenvolvimento e encerramento. Todavia, no Scrum estas 
fases são flexíveis e adaptáveis as necessidades dos clientes. 
O planejamento do Scrum se inicia com a escolha do Product Owner e do 
Scrum Master, eles definirão o Product Backlog, que são os requisitos iniciais do 
produto a ser entregue, e escolherão o Time de Desenvolvimento que será 
responsável pelos Sprints. (DESENVOLVIMENTO ÁGIL, 2020). 
 
SCHWABER e SUTHELAND (2013) no Agile Guide afirmam que: 
 
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, 
durante o qual um “Pronto”, versão incremental potencialmente utilizável do 
produto, é criado. Sprints tem durações coerentes em todo o esforço de 
desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão 
da Sprint anterior. As Sprints são compostas por uma reunião de 
planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, 
uma revisão da Sprint e a retrospectiva da Sprint. 
 
Antes do início de cada Sprint, acontecem as reuniões de planejamento do 
Sprint, chamada de Sprint Planning Meeting, onde o Product Owner apresenta as 
prioridades do Product Backlog. Nesta reunião o Time de Desenvolvimento 
seleciona quais as atividades poderão ser entregues no Sprint, assim as tarefas do 
Product Backlog são transferidas para o Sprint Backlog. (DESENVOLVIMENTO 
ÁGIL, 2020). 
Iniciada as atividades do Sprint, todos os dias serão realizadas reuniões de 10 
ou 15 minutos pela manhã, para que o Time de desenvolvimento possa avaliar o dia 
anterior e confirmar a programação priorizada para o dia. Essa reunião diária é 
chamada de Daily Scrum Meeting (BARACAT, 2016). 
 
29 
 
Ao final de cada Sprint, a equipe faz a apresentação das funcionalidades 
implementadas no produto em reunião chamada de Sprint Review Meeting, além 
disto é feito também uma retrospectiva, Sprint Retrospective. Por fim, encerrada tais 
ações, a equipe parte para o planejamento do novo Sprint, reiniciando o ciclo, 
conforme demonstra a figura 8. (DESENVOLVIMENTO ÁGIL, 2020). 
 
Figura 8 - Ciclo Scrum 
 
 
Fonte: Softhouse,2016 apud BODOCO, ALMEIA e LUCAS, 2018 2 
 
 
 
2 Disponível em: http://docplayer.com.br/137594815-Metodologia-agil-na-gestao-de-projetos-de-
software-mauricio-badoco-1-renato-inacio-de-almeida-2-carlos-alberto-de-lucas-3.html. Acesso em 08 
de agosto de 2020 
 
30 
 
3. METODOLOGIA TRADICIONAL VERSUS METODOLOGIA ÁGIL (SCRUM) 
 
As duas metodologias possuem importância atrelada ao tipo de projeto e aos 
cenários em que se encontram. Elas possuem semelhanças e diferenças e para 
escolha da metodologia adequada para um projeto o gerente deve entender as 
diferentes formar de se gerenciar, assim como conhecer as expectativas de seus 
clientes e o cenário ambiental em que se encontra. 
Segundo Lopes (2017 apud Sampaio, 2020), depois de analisar a 
metodologia tradicional, apresentada pelo PMBOK, e o Framework Scrum é possível 
entender as semelhanças e diferenças entre eles. Ressalta-se que a metodologia 
ágil surgiu exatamente para suprir lacunas da metodologia tradicional no 
desenvolvimento de softwares. Concatto (2017) diz que: 
 
As tendências ágeis estão à contrapartida dos métodos tradicionais (ou 
prescritivos), visto que estas abordagens buscam veemente o planejamento 
do projeto e produto como um todo desde o início. As metodologias ágeis 
defendem o processo incremental, ou seja, as entregas são feitas em 
blocos de modo que as partes interessadas participem de forma mais ativa 
no processo (CONCATTO, 2017). 
 
Em 2006, Ribeiro e Arakaki fizeram um comparativo entre o gerenciamento 
tradicional e o gerenciamento ágil, com foco nas áreas de processo do PMBOK, 
conforme demonstrado no quadro 2. 
 
 
 
 
 
 
 
 
 
 
 
31 
 
Quadro 2 - Quadro resumo/comparativo entre o gerenciamento tradicional e ágil 
 
Fonte: RIBEIRO, ARAKAKI, 2006. 
 
Prikladnicki (2014) realizou um comparativo entre as principais características 
da metodologia tradicional versus metodologia ágeis, conforme demonstrado na 
Tabela 1. 
 
 
 
 
 
 
 
 
 
 
 
 
 
32 
 
Tabela 1 - Comparativo Métodos Ágeis e Tradicionais 
 
 
Fonte: PRIKLADNICKI, 2014. 
 
3.1 Ciclo de Planejamento 
 
No que tange ao ciclo de planejamento, quando comparadas as duas formas 
de gerenciamento, percebe-se que o gerenciamento tradicional demora mais tempo 
na realização do planejamento, porque busca montar um planejamento que abrange 
completamente o projeto com riqueza de detalhes, incluindo além da Estrutura 
Analítica de Projeto – EAP, o planejamento das 10 áreas de processo do PMBOK. 
No Scrum, um planejamento inicial é realizado para definição do product 
backlog e escolha das competênciasiniciais do Time de Desenvolvimento. Todavia, 
o grande foco do planejamento está nas reuniões de Sprint Planning Meeting que 
são realizadas antes do início do Sprint. 
Para cada entrega de um Produto Mínimo Viável (PMV) construído por um 
Sprint é realizado um teste de funcionalidade e muitas vezes os produtos são 
 
33 
 
testados no mercado; desta forma, é possível avaliar a aderência às expectativas 
dos clientes e retroalimentar com feedback o planejamento dos próximos Sprints. 
(SAMPAIO, 2020). 
Nota-se que, em cenário de muitas mudanças, um projeto longo pode se 
tornar obsoleto mesmo ainda em fase de execução e, por isso, o gerenciamento ágil 
propõe a entrega de um produto inicial, que não tem todas as funcionalidades, mas 
que será aprimorado a partir do feedback dos clientes em cada rodada de Sprint, ou 
seja, os clientes influenciam no planejamento dos produtos. 
Segundo o Baracat (2016 apud SAMPAIO, 2020), os clientes são parte do 
projeto e: 
 
Participam diariamente da execução, a cada processo, e interage a cada 
resultado, enquanto na metodologia tradicional é dispendida grande energia 
em atender a tripla restrição, escopo, cronograma e custo, e o cliente fica 
em segundo plano, com isso as suas necessidades não são atendidas. 
(BARACAT, 2016 apud SAMPAIO, 2020). 
 
3.2 Avaliação de Resultados 
 
No gerenciamento tradicional, o projeto é monitorado e controlado ao longo 
do processo de execução, todavia o sucesso/resultado do projeto é medido apenas 
após o seu término, onde é feita uma avaliação quanto ao cumprimento do prazo, do 
escopo, do custo e da qualidade (VARGAS, 2018). 
Projetos como a construção de uma refinaria, por exemplo, são muito 
complexos e exigem uma enorme mobilização de recursos. Normalmente, este tipo 
de projeto dura entre 4 a 8 anos e a gestão de mudança precisa ser muito 
controlada, para que não haja riscos a segurança, quando na partida da unidade. É 
comum que neste tipo de projeto, o resultado seja avaliado após o término do 
projeto, quando a unidade entra em operação e os requisitos iniciais podem ser 
comparados ao resultado obtido pela unidade. 
No Framework Scrum, as avaliações ocorrem a cada rodada de Sprint, pois 
nas reuniões de Revisão são inspecionados os incrementos e feitas adaptações ao 
Backlog do produto, se necessário. Durante a Revisão de Sprint é feita avaliação do 
 
34 
 
valor agregado do incremento sobre o produto mínimo viável e o sucesso é definido 
sobre a percepção deste valor. Além disso, uma avaliação de sucesso, mesmo que 
parcial, ocorre durante a retrospectiva do Sprint, quando é feita uma análise sobre a 
condução desta etapa, avaliando a eficiência e eficácia do fluxo de comunicação, do 
cumprimento dos prazos e do consumo de recursos (SCHWABER; SUTHELAND, 
2013). 
 
3.3 Feedbacks 
 
O Feedback na metodologia tradicional acontece, em momentos específicos 
de monitoramento e controle, com o objetivo de ajustar o curso das atividades ao 
escopo planejado. A Estrutura Analítica de Projeto - EAP é a base do projeto e todos 
os entregáveis que constam nela precisam ser concluídos. Qualquer alteração na 
EAP, precisa passar por um rígido processo de gestão de mudança, onde é 
necessária a emissão de uma solicitação de mudança de projeto, que passará por 
um comitê de avaliação, composto por áreas técnicas, pelo gerente do projeto e por 
patrocinadores (VARGAS, 2018). 
No Scrum, a cultura de feedback é mais forte e o projeto é retroalimentado 
com a opinião dos clientes por meio do product owner, que a cada Sprint Planning 
Meeting apresenta as prioridades do próximo Sprint para o Time Scrum. Desta 
forma, o projeto não segue uma linha pré-definida de escopo, pois os requisitos 
podem ser alterados a partir da avaliação dos clientes. (SCHWABER; SUTHELAND, 
2013). 
Projetos de criação de um aplicativo de celular “app”, costuma utilizar o 
método Scrum. O time Scrum entrega um produto inicial ao mercado e a cada Sprint, 
sendo direcionados pelo Product Owner, vão adicionando ou alterando 
funcionalidades no app a partir da experiência dos clientes. Assim o produto vai 
sendo aperfeiçoado e moldado às necessidades reais dos clientes. Neste caso o 
feedback é constante ao longo do projeto. 
 
 
 
35 
 
4. RETOMADA DE OBRA PÚBLICA INACABADA 
 
Segundo o Manual de recomendações básicas para a contratação e 
fiscalização de obras de edificações públicas do Tribunal de Contas da União – 
TCU, Obra púbica é: 
 
Considerada toda construção, reforma, fabricação, recuperação ou 
ampliação de bem público. Ela pode ser realizada de forma direta, quando a 
obra é feita pelo próprio órgão ou entidade da Administração, por seus 
próprios meios, ou de forma indireta, quando a obra é contratada com 
terceiros por meio de licitação. Neste caso, são autorizados diversos 
regimes de contratação: 
• empreitada por preço global: quando se contrata a execução da 
obra ou do serviço por preço certo e total; 
• empreitada por preço unitário: quando se contrata a execução da 
obra ou do serviço por preço certo de unidades determinadas; 
• tarefa: quando se ajusta mão-de-obra para pequenos trabalhos por 
preço certo, com ou sem fornecimento de materiais; 
• empreitada integral: quando se contrata um empreendimento em 
sua integralidade, compreendendo todas as etapas das obras, 
serviços e instalações necessárias. 
 
A interrupção de uma obra é motivo de frustação para os gestores de projeto 
e ela pode acontecer por diversos motivos, como: falta de planejamento, falta de 
recursos financeiros, problemas climáticos, embargo judicial, mudança no mercado, 
mudança de governo, corrupção e desvio de dinheiro ou até por desistência dos 
patrocinadores (CAMPOS, 2013). 
Construir requer planejamento, recursos, conhecimento e tempo. Fatores 
externos e internos podem interferir na execução do projeto de uma obra, sendo que 
dos motivos citados no parágrafo acima, apenas a falta de planejamento e a falta de 
recursos são fatores internos (CAMPOS, 2013). 
O resultado da interrupção de uma obra é o desperdício de dinheiro e 
recursos público ou privado. As vezes as obras são até entregues inacabadas e com 
 
36 
 
má qualidade o que denigre o gestor de projetos, pois este carrega sobre os ombros 
o insucesso do projeto (COELHO, 2009). 
Andrade (2017) afirmou que o principal problema, relativamente às obras 
públicas, é “a negligência e o descaso quanto a legislação aplicável na licitação de 
obras e serviços, bem como às normas técnicas e conhecimentos de engenharia, 
tanto por parte da administração pública, quanto por parte da iniciativa privada”. 
A má gestão da governança e da gestão de projetos têm causado graveis 
prejuízos aos cofres públicos. Alcançar eficiência nesses dois sistemas é o desafio 
que o serviço público precisará solucionar para que consiga reduzir os índices de 
ocorrência de irregularidades em obra, atrasos, obras inacabadas ou 
empreendimento inservível. Os processos integrantes da gestão de governança e de 
projetos aumentam a probabilidade de sucesso da obra (ANDRADE, 2017 apud 
ALTOUNIAN, 2016). 
O foco de uma obra pública deve ser o atendimento às necessidades do 
cliente que neste caso é o povo. Ela não pode ir de encontro às necessidades reais 
da população e se não atender as necessidades destes, a obra deve ser 
reformulada (GOMES, 2007). 
 
4.1 Contexto Específico 
 
A obra analisada tratasse da retomada de construção do auditório central de 
uma empresa produtora de derivados de hidrocarbonetos em Pernambuco, que será 
chamada ficticiamente neste documento por empresa ABC. 
A empresa ABC iniciou em 2008 a construção de unidades industriais novas 
para montagem de uma unidade fabril completa em Pernambuco. Além das plantas 
industriais, foram construídas estruturas de apoio para a futura equipe de apoio à 
produção, como prédios administrativos, centrais de comando, laboratórios,centros 
educacionais, torres de comunicação e auditórios. 
Todavia, em 2015, sugiram denúncias de corrupção e desvio de recursos da 
obra, por meio de aditivos com preços superfaturados e pré acordados entre 
empreiteiros e diretores da Companhia. O escândalo ganhou proporções nacionais e 
a Justiça bloqueou o caixa de todas as empreiteiras que atuavam na obra, desta 
forma a obra foi interrompida sem que houvesse um planejamento de parada. O 
 
37 
 
dano a empresa ABC foi muito grande, pois além de ter que lidar com a mídia, com 
órgãos de controles, se viu com dinheiro investido em uma obra que estava 
paralisada e que não servia para fazer retornar o seu investimento. Com muita 
dificuldade, a empresa ABC conseguiu partir uma unidade industrial de refino de 
hidrocarboneto bruto e isto pôde trazer caixa para a empresa, todavia era notório o 
abandono que havia acontecido na empresa. Era possível visualizar restos de obra e 
entulhos espalhados por toda empresa e muitos dos canteiros de obra não foram 
destruídos, foram abandonados, inclusive com material já comprado dentro. 
O Auditório Central, com capacidade para 200 pessoas, foi uma dessas obras 
inacabadas. A empresa ABC contratou uma empresa por preço Global para 
construção deste prédio e a obra foi gerenciada utilizando-se a metodologia 
tradicional de gerenciamento de projetos. Quando a obra estava com 85% de 
conclusão, ela foi interrompida e passou 3 anos parada. Havia sido concluída toda a 
fundação do prédio, as paredes foram erguidas e o telhado instalado. 
O sistema hidráulico estava 95% instalado, mas o prédio não havia sido 
ligado ao sistema de água e escoto da empresa. O sistema de refrigeração estava 
com 69% e o sistema elétrico estava com 40% de avanço. 
A empresa ABC havia gasto certa de R$ 3,5 milhões neste projeto e agora o 
prédio não podia servir a finalidade para o qual foi criado. Quando os gestores 
queriam fazer uma reunião com todos os funcionários, eles programavam entre 4 a 6 
ônibus que recolhiam os funcionários e os levava para um auditório que existia 
dentro da planta industrial em um canteiro provisório de obra. 
O deslocamento de ida e volta deste canteiro gastava em torno de 30 minutos 
de cada indivíduo da força de trabalho, ou seja, eram 30 minutos de hora 
improdutiva, translado, para cada funcionário a cada reunião geral. 
Por fim, a Engenharia da empresa ABC decidiu concluir a obra do auditório 
com recursos que estivessem já disponíveis na empresa, sem que houvesse a 
necessidade de grandes contratações de mão de obra, nem de material. 
Quando a empresa ABC tomou esta decisão, ela informou que a tripla 
restrição havia mudado e que as prioridades não seriam mais escopo, custo e prazo. 
Ela informou ao time que queria o prédio pronto independente da especificação 
inicial do escopo e a equipe estaria livre para fazer alterações na arquitetura desde 
que o prédio fosse inaugurado dentro de 8 meses, que fosse gasto no máximo R$ 1 
 
38 
 
milhão e que fosse utilizado o máximo de material já disponível dentro da empresa 
ABC. 
A dificuldade principal do gerente de projeto neste caso, é porque apesar dele 
possui a EAP dos projetos e as plantas de engenharia. Ele gastaria muito tempo e 
recursos para levantar tudo o que já fora feito pela empreiteira anterior e não havia 
registro de planejamento da interrupção da obra. Neste caso ficava difícil montar um 
orçamento e um cronograma no formato tradicional, seguindo as regras do PMBOK. 
 
4.2 Metodologia Ágil aplicada na retomada de obra inacabada 
 
Cada projeto tem suas particularidades e cabe ao gerente do projeto escolher 
a melhor ferramenta de gestão que irá suportar a condução dos processos rumo ao 
atingimento dos objetivos principais. (PMI, 2017) 
O gerente de projeto decidiu então convocar a equipe de engenharia e 
solicitou a que eles avaliassem se a infraestrutura básica estava pronta e a equipe 
concluiu que a fundação, paredes e teto estavam prontos e que os sistemas 
hidráulicos, elétricos e de refrigeração, precisariam ser simplificados e adaptados. 
Desta forma, o gerente do projeto, juntamente com a equipe, decidiu montar um 
cronograma simples que pudesse dar um norte geral para todos e optou pela 
utilização de um método de gerenciamento utilizando o SCRUM. 
Grande parte desta decisão foi apoiada pela alteração das prioridades da 
tripla restrição (Escopo, Prazo, Custo). Anteriormente o foco estava no cumprimento 
do escopo predefinido na EAP e este escopo previa um auditório muito luxuoso e 
tecnológico. O foco atual passou a ser a entrega de um ambiente que pudesse ser 
utilizado confortavelmente pelos funcionários da empresa. 
O gerente da Engenharia escolheu então um Product Owner e eles definiram 
os requisitos mínimos do “novo projeto”, construindo o Backlog Product, e montaram 
o time de desenvolvimento. 
O Scrum Master explicou a forma de gestão e apresentou os integrantes do 
time. A primeira reunião de planejamento do Sprint definiu as tarefas que seriam 
realizadas nas próximas 2 semanas; definiu quais os materiais seriam utilizados, 
disparou os pedidos de compra para a quinzena seguinte e recolheu a aprovação do 
Product Owner com relação as mudanças sobre o projeto original. 
 
39 
 
O Time de Desenvolvimento tinha autonomia para definir como o trabalho 
seria feito e todos participavam ativamente do planejamento, desde o engenheiro até 
o pedreiro, pintor e eletricista. 
O cronograma base foi criado pelo Time de Desenvolvimento, junto com o 
Scrum Master e o Product Owner, principalmente para que se pudesse enxergar as 
interfaces e ordem de prioridade entre os processos, todavia o planejamento das 
tarefas era realizado a cada Sprint Planning Meeting. 
Ao projeto foi dado flexibilidade para alteração da especificação dos materiais 
desde que aprovado pelo Product Owner. E isto foi muito importante, conforme 
explicado anteriormente, a Empresa ABC possuía muitos canteiros abandonados e 
neles haviam materiais que puderam ser reciclados, como luminárias, forro 
acartonado, lâmpadas, pias, tomadas, lixeiros e produtos novos ainda embalados, 
como poltronas para auditório, piso laminado, placa Eucatex de revestimento para 
parede. 
Diariamente a equipe se reunia no início do dia, por 15 minutos, e passavam 
as ações que deveriam ser executadas durante o dia, alinhando as necessidades, 
removendo gargalos e avaliando o dia anterior. 
A cada final de Sprint, a equipe fazia uma avaliação das ações realizadas na 
quinzena e corrigiam o curso do projeto quando necessário. Assim, o ciclo rodava e 
o time fazia reunião de planejamento do novo Sprint. 
O projeto utilizou o Framework Scrum até a sua conclusão e entrega. Os 
clientes ficaram muito satisfeitos e perceberam valor agregado entregue pelo 
projeto, pois o objetivo de tornar o prédio útil para a força de trabalho foi alcançado e 
pela primeira vez, depois de toda a confusão oriunda das denúncias de corrupção, a 
empresa pode reunir toda a força de trabalho em um local confortável e adequado 
para uma reunião, proporcionando um senso de unidade e superação em toda a 
equipe. Além disso, o projeto terminou dentro do prazo de 8 meses e foi concluído 
com 70% do orçamente estimado inicialmente. O cliente achou o Auditório muito 
bonito, funcional e adequado as suas necessidades. O Time Scrum permaneceu 
motivado durante a execução de todo o projeto. 
 
 
40 
 
As alterações feitas pelo Time Scrum foram registradas nas plantas originais 
do projeto, principalmente as de elétrica e refrigeração, e arquivadas no banco de 
dados da engenharia. 
 
41 
 
 5. CONCLUSÃO 
 
O objetivo deste trabalho foi comparar a metodologia tradicional com os 
métodos ágeis e avaliar a viabilidade de utilização do SCRUM como um framework 
de gestão na retomada de uma obra inacabada em uma empresa de produção de 
derivados de hidrocarbonetos. 
O trabalhoexpôs robustamente a teoria que envolve a metodologia 
tradicional, registrada no PMBOK, e os métodos ágeis com maior foco ao 
detalhamento do método de Framework Scrum. Além disso, o trabalho apresentou 
uma obra civil em que foram utilizadas as duas metodologias e esclareceu que o 
contexto da obra pode alterar a decisão do gestor sobre qual modelo de 
gerenciamento de projeto escolher. 
Conclui-se que não existe uma metodologia melhor que outra. A correta 
escolha de qual método de gerenciamento de projeto utilizar é dever do gestor de 
projetos e impacta fortemente no resultado de sucesso e na efetividade da entrega. 
É de suma importância que o gestor conheça as diversas técnicas e métodos e 
saiba compará-las entre si e com o cenário no qual se encontra. A comparação entre 
as duas formas de gerenciamento de projetos foi realizada no item 4, deste 
documento, e demonstra que a metodologia tradicional é mais adequada para 
projetos que não sofrerão tantas alterações, com longos prazos e pouca 
flexibilidade. Já o Scrum é mais apropriado para projetos que necessitam de 
flexibilidade, em virtude da presença constante do cliente dando feedback sobre a 
usabilidade do produto ofertado. Além disso, o Scrum se adapta melhor aos cenários 
onde as entregas são de curto prazo e a equipe tem capacidade de atuar de forma 
autônoma. Equipes que precisam frequentemente da orientação direcionadora de 
um líder, não serve para formar um time Scrum. 
No caso do auditório, mesmo sendo o mesmo prédio que estava sendo 
construído, este passou por duas formas de gestão diferentes. No início a obra foi 
gerenciada pelo sistema de gestão tradicional do PMBOK e após a interrupção não 
planejada o projeto foi retomado, desta vez, utilizando o método de gestão Scrum e 
a obra foi por fim concluída. Os cenários anteriores e posteriores à parada do 
projeto adquiriram características muitos peculiares com prioridades e objetivos 
 
42 
 
diferentes, isto fez mudar a análise do Gerente de projetos quanto ao método de 
gestão e por isso ele escolheu o método Scrum para esta nova etapa, por ele 
precisar de flexibilidade e agilidade para alterar o projeto de modo a utilizar materiais 
e recursos já existentes na empresa. Além disso, ele precisava do cliente por perto, 
dando feedback e aceite sobre as alterações que estavam sendo feitas a cada 
Sprint. Para que o projeto desse certo, as decisões precisavam ser rápidas e tudo 
isto aconteceu de fato, contribuindo para o sucesso do projeto e entrega do produto 
final, gerando valor para a empresa ABC. 
 
 
 
 
43 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
AGILE GUIDE: Agile Practice Guide / Project Management Institute – PMI e Agile 
Alliance®. EUA, Pennsylvania: PMI, 2017. 
ALTOUNIAN, C. S. Obras Públicas: licitação, contratação, fiscalização e utilização. 
Belo Horizonte: Forúm. 5ª Edição. 2016. 
ANDRADE, V. H. M. Contratação, Execução e Fiscalização de Obras Públicas: 
Estudo das práticas adotadas e suas consequências. Graduação do Curso de 
Engenharia Civil da Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2017. 
BARACAT, CÉSAR C. Gerenciamento de Projetos: Um confronto entre metodologias 
ágeis e tradicionais. Curso de Engenharia de Produção, Universidade Federal de 
Juiz de Fora, Juiz de Fora, 2016. 
BISSI, W. Scrum: Metodologia de Desenvolvimento Ágil. Centro Universitário de 
Maringá, Paraná, 2007. Disponível em: 
http://revista2.grupointegrado.br/revista/index.php/campodigital/article/view/312 
BODOCO, M.; ALMEIDA, E. I.; LUCAS, C.A. Metodologia Ágil na Gestão de Projetos 
de Software. FATEC. Graduação em Análise e Desenvolvimento de Sistemas. São 
Paulo: Revista EduFatec (educação, tecnologia e Gestão). 2018. 
BORBA, H. Fatores Críticos de sucesso de um projeto. 2015. 
http://heitorborbasolucoes.com.br/fatores-criticos-de-sucesso-de-um-projeto/ 
.Disponível em: 02 de agosto 2020 
BUILDER, Project. Gestão de projetos: Ágil ou tradicional? Entenda as diferenças. 2017. 
Disponível em: https://www.projectbuilder.com.br/blog/gestao-de-projetos-agil-ou-
tradicional-entenda-as-diferencas/. Acesso em: 12 de agosto de 2020. 
CAMPOS, I. M. Obra parada: Resultado de falta de planejamento e de 
administração. Instituto Brasileiro de Desenvolvimento de Arquitetura. 2013. 
Disponível em: 
http://www.forumdaconstrucao.com.br/conteudo.php?a=12&Cod=140. Acesso em: 
10 de agosto de 2020. 
 
44 
 
COELHO, A. B. P. Obras e serviços de engenharia: licitações e contratos. Minicurso. 
TCEMG, 2009. 
COUTO, Júlia M. C. Métodos Ágeis & PMBOK: Uma Revisão Sistemática da 
Literatura sobre o uso de Abordagens Híbridas no Gerenciamento de Projetos de 
Software. Faculdade Estácio, MBA Gestão de Projetos.[S.I.]. 2016. 
D’ÁVILA, Márcio. PMBOK e gerenciamento de projetos. Disponível em: 
http://www.mhavila.com.br/topicos/gestao/pmbok.html. Acesso em: 02 de agosto de 
2020 
 desenvolvimento de software. Porto Alegre: Bookman, 2014. 
GONÇALVES, ROBSON N. Estudo comparativo entre PMBOK e os métodos ágeis 
aplicados ao gerenciamento de projetos de Software. MBA em Gerenciamento de 
Projetos. Fundação Getúlio Vargas, Salvador, 2018. Disponível em: 
https://www15.fgv.br/network/tcchandler.axd?tccid=8000 
HAROLD, R. K. Project Management: a systems approach to planning, scheduling 
and controlling. [S.l.]: Editora Edgard Blücher, 2015. 
KOONTZ, H.;O’DONNEL, C. Os princípios da Administração: Uma análise das 
funções administrativas. São Paulo: Pioneira, 1980 
LAMB, J. C. Gestão de Projetos X Gestão de Processos: Qual a Diferença? [S.I.] 
Disponível em https://www.lamb.eng.br/gestao-de-projetos-x-gestao-de-processos-
qual-a-diferenca. Acesso em 27/07/2020. 
LAWRENCE, Paul R.; LORSH, Jay W. New management job: The integrator. Havard 
Business Review.[S.I.] 1967 
LOPES, LUÍSA P. Aplicação da metodologia scrum em uma área de engenharia de 
processos de uma empresa do varejo. 2017. 98 f. TCC (Graduação) - Curso de 
Engenharia de Produção, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 
2017. 
 
45 
 
NORO, Greice de Bem. A Gestão de Stakeholders em Gestão de Projetos. Revista 
de Gestão e Projetos – GeP v. 3, n. 1, p. 127 – 158 , 1 abr. 2012 
OBRA PÚBLICA: Recomendações básicas para a contratação e fiscalização de 
obras de edificações públicas. Brasília: Tribunal de Contas da União. 4ª edição. 
2014. 
PMI, Project Management Institute. Um Guia do Conhecimento em Gerenciamento 
de Projetos (Guia PMBOK). São Paulo: [S.I.], 5 edição, 2013b. 
PMI, Project Management Institute. Um Guia do Conhecimento em Gerenciamento 
de Projetos (Guia PMBOK). São Paulo: [S.I.], 6 edição, 2017. 
PRIKLADNICKI, R. et al. Agile Manifesto: Manifesto para Desenvolvimento Ágil de 
Software, 2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. 
PRIKLADNICKI, Rafael; WILLI, Renato; MILANI, Fabiano. Métodos Ágeis para 
RIBEIRO, ANDRÉ L. D.; ARAKAKI, REGINALDO. Gerenciamento de Projetos 
Tradicional x Gerenciamento de Projetos Ágil: Uma análise comparativa. 3º 
Congresso Internacional de Gestão de Tecnologia e Sistemas de Informação e 11th 
World Continuos Auditing Conference. São Paulo, 2006. 
ROWE, SANDRA F. Project Management for Small Projects. Oakland: Ed. Berrett-
Koehler Publishers, 3ª Edição, 2020 
SAMPAIO, JULIANA A. V. Gerenciamento de Projetos: uma comparação entre as 
metodologias tradicional e ágil. MBA em Gerenciamento de Projetos. Fundação 
Getúlio Vargas. Salvador. 2020 
SCHWABER, K; SUTHELAND, J. Scrum Guide: as regras do jogo. EUA: [S.I.], 2013 
SITE DESENVOLVIMENTO ÁGIL. Scrum. Disponível em: 
https://www.desenvolvimentoagil.com.br/scrum / Acesso em: 08 de agosto de 2020. 
 
46 
 
SOFTHOUSE. Scrum in five minutes. Disponível em: 
https://issuu.com/softhouse/docs/scrum_5min_eng_131210. Acesso em: 11 de julho 
2016. 
TORREÃO, PAULA G. B. Project management knowledge learning environment: 
ambiente inteligente de aprendizado para educação em gerenciamentode projetos. 
2005. Tese (Mestrado) – Centro de Informática, Universidade Federal de 
Pernambuco, Pernambuco, 2005. Disponível em: https://repositorio.ufpe.br 
VARGAS R. V. Manual Prático do Plano de Projeto: Utilizando o PMBOK® Guide. 
São Paulo: Brasport, 6ª edição, 2018. 
VERZUH, Eric. MBA Compacto: Gestão de Projetos. Rio de Janeiro: Elsevier, 2000 
VICENTINO, C. História Geral. São Paulo: Editora Scipione. 1997