Embed Size (px)
Citation preview
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
valor ao 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 burocracia podia 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ção de 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 problemas complexos 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ências iniciais 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 trabalho expô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 gerenciamento de 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
