tcc - francisco elder cabral junior - gp-55
DESCRIPTION
GERENCIAMENTO DE MUDANÇAS EM EMPRESA DE PROJETOS DE ENGENHARIATRANSCRIPT
FRANCISCO ELDER CABRAL JUNIOR
GERENCIAMENTO DE MUDANÇAS EM EMPRESA DE
PROJETOS DE ENGENHARIA
Trabalho apresentado ao curso MBA em
Gestão Empresarial com ênfase em
Gerenciamento de Projetos Pós-
Graduação lato sensu, da Fundação
Getúlio Vargas como requisito parcial para
a obtenção do Grau de Especialista em
Gerenciamento de Projetos.
ORIENTADOR: Prof.ª Marta Cardoso de Lima da Costa R ego
Rio de Janeiro - RJ
Setembro/ 2011
i
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV Management
MBA em Gerenciamento de Projetos
O Trabalho de Conclusão de Curso
GERENCIAMENTO DE MUDANÇAS EM EMPRESA DE PROJETOS DE
ENGENHARIA
elaborado por Francisco Elder Cabral Junior
e aprovado pela Coordenação Acadêmica do curso de MBA em Gestão Empresarial
com ênfase 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 da FGV.
Rio de Janeiro, 21 de setembro de 2011.
André Baptista Barcaui
Coordenador Acadêmico Executivo
Marta Cardoso de Lima da Costa Rego
Prof. Orientador
ii
TERMO DE COMPROMISSO
O(a) aluno(a) Francisco Elder Cabral Junior, abaixo assinado, do curso MBA em
Gerenciamento de Projetos, Turma GP-55 BOTA, realizado nas dependências da
FGV, no período de 01/04/10 a 21/06/11, declara que o conteúdo do Trabalho de
Conclusão de Curso intitulado Gerenciamento de Mudanças em Empresa de
Projetos de Engenharia, é autêntico, original e de sua autoria exclusiva.
Rio de Janeiro, 21 de setembro de 2011.
Francisco Elder Cabral Junior
iii
Dedicatória:
Dedico este trabalho à minha
companheira Marília, que me deu a força
e o incentivo para volta a sala de aula, e a
minha família que foi responsável por
moldar o meu caráter.
iv
AGRADECIMENTOS
À minha orientadora, que me acompanhou nas 'intempéries e nas borrascas do
questionamento', eliminando as minhas dúvidas, e que, magistralmente, orientou o
meu pensamento para tirar minhas ideias das pontas dos meus dedos e transportá-
las para as páginas desse trabalho.
Ao Sr. Mário Santos e a Srª. Cintia Pimentel, diretores da Exactum Consultoria
e Projetos, pelo apoio e incentivo para fazer este curso;
Aos meus professores do curso de MBA da FGV, em especial, ao professor
Fábio Bahia, que me forneceu a ideia e me auxiliou na execução, dando-me
subsídios realizar este estudo.
Ao colega de Instituto Militar de Engenharia, Luciano Sales, pelo apoio e pelas
indicações bibliográficas.
Ao restaurante e bar Chic do Rio Sul, na figura de um dos seus donos, Sr.
Beto, que me cedeu um espaço para ler os tantos livros que viraram tantas citações.
Ao meu querido cachorro, Iupe. Ele que foi meu companheiro nas noites mal
dormidas, que ficou com sua cabeça em cima do meu pé enquanto nas madrugadas
escrevia partes desse trabalho.
À minha esposa e companheira, Marília, que entendeu minha ausência em
alguns momentos, entendeu as “reuniões do escritório”, que aconteciam depois das
provas, e que me deu a força e o incentivo para voltar à sala de aula e a continuar
os meus estudos.
A Deus, por tudo que Ele tem me dado, por atender as minhas preces e por ter-
me dado paciência e tempo para compreender algumas questões sobre o existir-no-
mundo.
v
RESUMO
Neste trabalho foi realizada uma pesquisa bibliográfica buscando as relações
entre metodologias tradicionais de gerenciamentos de projeto, boas práticas
defendidas pelo Project Management Institute (PMI), e as metodologias ágeis de
gerenciamento de projetos. O autor do trabalho mostra as origens do gerenciamento
de projetos e enfatiza no estudo do gerenciamento de mudanças em projetos,
buscando o enfoque de como essas duas metodologias citadas tratam o
atendimento das solicitações de mudanças que ocorrem durante o projeto.
Palavras Chave: metodologias ágeis, gerenciamento de mudanças.
vi
ABSTRACT
In this work was realized a bibliography research looking for the relation
between the traditional methodology of project management, good practices
advocated by Project Management Institute (PMI), and the agile methodologies of
the project management. The work shows the origins of the project management
and emphasizes the study in the change management in project, seeking to focus as
these methodologies treat change requests in the project.
Key Words: agile methodologies, change management
vii
SUMÁRIO
1. INTRODUÇÃO .................................................................................................................. 10
2. HISTÓRICO DO GENRECIAMENTO DE PROJETOS .............................................. 11
3. METODOLOGIA DE GERENCIAMENTO DE MUDANÇAS ..................................... 25
METODOLOGIA PMI (PROJECT MANAGEMENT INSTITUTE) .................................................... 29
METODOLOGIA APM (AGILE PROJECT MANAGEMENT) ......................................................... 38
PRINCIPAIS DIFERENÇAS ENTRE AS METODOLOGIAS .............................................................. 44
4. CONCLUSÕES ................................................................................................................. 48
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................. 50
viii
LISTA DE FIGURAS
Figura 1 – Pirâmide de Gizé ................................................................................................ 11
Figura 2 – Muralha da China ................................................................................................ 12
Figura 3 – Coliseu de Roma ................................................................................................ 13
Figura 4 – Parthenon ........................................................................................................... 13
ix
LISTA QUADROS
Quadro 1 – Os processos do PMBOK ................................................................................. 22
Quadro 2 – Diferenças entre uma abordagem tradicional e uma adaptável ......................... 43
10
1. INTRODUÇÃO
Neste trabalho tem como objetivo mostrar ao leitor a importância do
gerenciamento de mudanças para o gerenciamento de projeto e como as
metodologias consagradas recomendam que o tema seja tratado. Em todo projeto
pode acontecer mudanças no decorrer do mesmo, será visto o quanto é fundamental
ser adaptar rapidamente a essas mudanças.
No segundo capítulo será feito um breve histórico do gerenciamento do projeto,
de sua evolução durante os anos. Desde quando não era conhecido com esse nome
nas pirâmides do Egito até as boas práticas defendidas pelo Project Management
Institute (PMI), passando por experiência em projetos modernos que criaram
ferramentas importantes com o PERT e os gráficos de Gantt.
No terceiro capítulo será retratado um contexto geral do gerenciamento de
mudanças em projeto, sua importância dentro do projeto e como alguns autores
tratam esse tema. Posteriormente será feito um resumo da metodologia aplicada
pela PMI com relação a mudanças no decorrer do projeto, quais os processos que
são realizados quando há uma solicitação de mudança e como essa é
implementada. Em seguida será exposta uma metodologia diferente para se tratar
das mudanças em projeto conhecida como Agile Project Management traduzindo,
Gerenciamento Ágil de Projetos. Será feito um pequeno histórico do surgimento de
tal metodologia com diversas citações de autores renomados no tema. E finalmente
serão apontadas as principais diferenças entre as duas metodologias
A seguir uma breve conclusão sobre a aplicação de tais metodologias no
gerenciamento de projeto. Quais os aspectos que devem ser levados em conta para
que se possa tomar a decisão de qual metodologia melhor se adequa ao tipo de
projeto que o gerente de projetos está envolvido.
11
2. HISTÓRICO DO GENRECIAMENTO DE PROJETOS
Sabendo de sua importância para entendimento do tema, esse capítulo será
iniciado por um breve contexto histórico do gerenciamento de projetos. Esse tema é
relativamente recente, seus estudos constam de meados do século passado (2007,
p. 17). Apesar de ser uma novidade, seus conceitos eram usados mesmo antes do
nome Gerenciamento de Projetos.
A história nos remete a grandes obras da humanidade, como por exemplo, as
famosas pirâmides do Egito, mais especificamente a Pirâmide de Gizé. Na sua
construção foram necessários cerca de 100 mil trabalhadores e levou cerca de 30
anos para ser construída1. Mesmo naquela época existia a figura o único
responsável pelas tarefas dos “trabalhadores” que eram na verdade os escravos
hebreus. Além de uma logística gigantesca para se trabalhar com tantas pessoas ao
mesmo tempo, tinha o controle de conflito que sempre estava presente, já que os
trabalhadores em questão não estavam contentes por trabalhar como escravos.
Apesar do sucesso de sua construção podemos citar problemas que ocorreram
durante sua construção como a negociação entre o “Sponsor” do projeto, o Faraó, e
Moisés que estava representando o povo hebreu. O que culminou com a fuga do
povo hebreu pelo Mar Vermelho que nos dias de hoje equivaleria a falta de mão de
obra.
Figura 1 – Pirâmide de Gizé Fonte: http://www.loc.gov
1 Site http://www.portalsaofrancisco.com.br/ acessado em 13/04/2011
12
A construção da Muralha da China, uma construção feita no ano 221 a.C. por
determinação do Imperador Qin Shihuang. A muralha foi construída com o objetivo
de proteger o reinado das invasões do povo Mongol. Durante a dinastia Qin tinha
três quilômetros de extensão, porém durante a ascensão da dinastia Han os
trabalhos de reconstrução foram retomados por volta de 206 a.C. e finalmente
chegando ao formato atual no século XV durante a dinastia Ming, chegando a uma
extensão total de 8850 mil quilômetros2. Esta é uma das construções feitas pelo
homem que pode ser vista até mesmo do espaço.
Figura 2 – Muralha da China Fonte: http://www.panoramio.com/photo/11611768
Para citar construções ocidentais de renomado vulto pode-se citar a construção
do Coliseu de Roma e o Parthenon na Grécia. O Coliseu é uma exceção aos
anfiteatros da época por conta de sua grandiosidade. Tinha capacidade para 50 mil
pessoas, 48 metros de altura e cerca de 80 entradas e saídas. Foi construído em
cerca de 8 a 10 anos por volta de 70 a 90 a.C, sendo iniciado pelo imperador
Vespasiano e concluído pelo imperador Tito. Nessa construção já foram usadas
tecnologias de engenharia com o concreto e a drenagem de um lago no lugar que ia
ser construído o Coliseu3.
2 Site http://fortalezasmultimidia.com.br. Acesso: 16 abr. 2011
3 Site http://www.nea.uerj.br/publica/e-books/mediterraneo1/DOC/Leandro%20Gaviao.pdf. Acesso: 11 jun. 2011
13
Figura 3 – Coliseu de Roma Fonte: http://www.panoramio.com/photo/41281226
Com relação ao Pathernon foi, ele construído como um templo para o culto a
Deusa grega Athenas. Foi construído por volta do século V a.C na Acrópole de
Atenas. Parte dessa estrutura esta de pé até hoje e é um dos edifícios mais
conhecidos na Grécia. O Pathenon foi construído para substituir um templo que
havia sido destruído pela invasão persa. Nessa construção já havia a figura de um
responsável centralizado, Fidias que era o responsável pela estabilidade estrutural e
Iktinos que era o arquiteto4.
Figura 4 – Parthenon http://www.panoramio.com/photo/1245481
Uma característica comum entre essas obras citadas é que a variável tempo
não era fundamental, muitos dos “Sponsors” dessas obras não chegaram a vê-las
prontas. Porém mais recentemente com as mudanças que aconteceram depois da
4 Site http://odysseus.culture.gr/ Acesso: 16 abr. 2011
14
Revolução Industrial e ascensão do capitalismo o tempo passou a ser levado em
conta e não somente isso, o tempo se tornou uma variável tão importante quanto o
custo. Afinal de contas o mundo estava mudando e cada vez mais aconteciam
avanços tecnológicos que faziam as construções ficarem prontas cada vez mais
rápidas.
Era uma época de empreendedorismo, o volume de dinheiro era grande e a
participação do governo era mínima com uma regulamentação simples. As primeiras
teorias do gerenciamento de projeto surgiam principalmente com Taylor (1911) e
Gantt (1919) que eram baseadas em regras simples de administração e
organização.
Henry Gantt desenvolveu para a marinha americana um sistema de controle
que é muito famoso até os dias de hoje, os gráficos de barras de Gantt. Há uma
divergência entre alguns autores de quando essa ferramenta foi usada pela primeira
vez. Valle (2007, p. 25) cita que o método foi utilizado nas construções de navios
durante a Primeira Guerra Mundial, já Peter W. G. Morris em The Management of
Project citado por Fábio Braga de Oliveira (OLIVEIRA, 2009) fala que essa
ferramenta foi utilizada durante a produção do Frankford Arsenal em 1917.
No mesmo trabalho o autor cita que durante os anos 20 e 30 algumas técnicas
de gerenciamento de projetos começaram a ser usadas por algumas empresas
como a Procter and Glambe e a Exxon e pela US Air Corps. Nessa época as
empresas eram organizadas ou de maneiras piramidal ou funcional onde há pouca
interação entra as áreas, pois está organizada em cadeias de comando.
A indústria militar foi a impulsionadora para o desenvolvimento do
gerenciamento de projeto. Com a guerra da Coréia e o medo da Guerra Fria
aumentou a necessidade de melhores coordenações entre a engenharia e a
produção. Durante os anos 50 o departamento de defesa dos Estados Unidos
passou a utilizar técnicas como o PERT (Program evaluation and review technique)
nos projetos de aeronaves e mísseis de longos alcance como o Atlas e o Polaris.
Nesse mesmo período a Du Pont, empresa da indústria de construção, passou a
utilizar o CPM (Critical Path Method) em seus projetos, esse método é conhecido no
Brasil com o Método do Caminho Crítico.
15
Nos anos 60 com a chegada a presidência de John Kennedy e junto com ele
Robert McNamarra como Secretário de Defesa uma série de processos foram
adotados na USAF (United States Air Force). Uma ferramenta muito importante no
Gerenciamento de Projeto foi usada nessa época, a EAP (Estrutura Analítica de
Projetos) ou WBS (Work Breakdown Structure). Essa técnica foi utilizada durante a
corrida espacial pela NASA no programa Apollo por um defeito conhecido da
ferramenta PERT no controle de custos (OLIVEIRA, 2009). E para acompanhamento
de maneira dinâmica os relatórios de custos foi desenvolvido o sistema de valor
agregado (Earned Value System).
Esses e outros projetos são referências da capacidade humana de conduzir
grandes projetos com sucesso. Mas afinal de contas, o que é um projeto e qual o
verdadeiro significado do sucesso.
Segundo o PMBOK5 projeto “é um esforço temporário empreendido para criar
um produto, serviço ou resultado exclusivo”. Ainda de acordo com a Norma
ISO 10.006 (Diretrizes para Qualidade de Gerenciamento de Projetos), o projeto é
“um processo único, consistindo de um grupo de atividades coordenadas e
controladas com datas de inicio e término, empreendido para o alcance de um
objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e
recursos.” Assim os projetos guardam algumas características únicas: aprendizado
por meios de erros, temporariedade, singularidade, progressividade (VALLE,
PEREIRA, et al., 2007).
Todo projeto pode haver erros. Isso não exime os projetos similares no futuro
de não terem erros, mas também não quer dizer que vamos continuar cometendo os
mesmo erros para sempre. Afinal de contas o fracasso faz com que as pessoas
prestem mais atenção para que elas não cometam os mesmos erros novamente.
Cada projeto é um aprendizado para os projetos futuros, empresas como a Boeing
mantêm um banco de dados com erros de projetos anteriores (VALLE, PEREIRA, et
al., 2007).
5 PROJECT MANAGEMENT INSTITUTE – PMI. Guia PMBOK é um guia dos conjuntos de
conhecimentos do gerenciamento de projetos que será abordado mais a frente.
16
A indústria aeronáutica investe pesado para aprender com os erros cometidos.
Um exemplo disso foi o acidente do voo 4590 da Air France de um avião do tipo
Concorde que ocorreu em 25 de julho de 2000. Um dos motores incendiou e o avião
caiu logo depois da decolagem matando todos os passageiros a bordo. A causa do
acidente era desconhecida, até porque o Concorde era um dos aviões mais seguros
da época. Feita uma investigação em torno do acidente descobriu-se uma peça de
metal solta na pista do aeroporto Charles De Gaulle que houvera se soltado de um
avião DC-10 que havia decolado antes do avião Concorde. Os Investigadores
descobriram que a peça de metal havia cortado um dos pneus do avião, que
desprendeu um pedaço de borracha e danificou o trem de pouco. O pedaço de
borracha também atingiu o tanque de combustível e a fagulhas dos fios do trem de
pouso iniciaram o acidente que terminou com a morte das 109 pessoas a bordo. O
projeto dos tanques e principalmente dos pneus foram repensados, criando um
revestimento ao redor dos tanques e pneus mais resistentes. Infelizmente, isso não
foi suficiente para impedir a aposentaria dos aviões em 2003. Porém as melhorias
nas tecnologias ainda são utilizadas nos aviões comercias de hoje em dia. Com isso
aprendemos que em projetos as falhas têm que ser discutas e não escondidas.
Todo projeto tem inicio, meio e fim, ele só para quando seus objetivos são
alcançados, quando ele não é mais necessário ou quando alcançar seu objetivo não
é mais economicamente viável. Isso consiste a temporariedade dos projetos.
Todo projeto é único, isto é singular, eles geram produtos ou serviços únicos.
Mesmo sendo o mesmo projeto, empresas diferentes irão gerenciá-los de maneira
diferente, pois a implementação da gerência de projeto deve ter como base a cultura
de cada organização.
Todo projeto também é progressivo e contínuo, isto é, são organizados por
etapas cronológicas. Essa é a característica de sua progressividade.
Os projetos vão além da porta das empresas, por isso é uma das ferramentas
para o desenvolvimento dos objetivos estratégicos da empresa. Mas para
implementar a visão estratégica das empresas, os projetos precisam ter sucesso.
Mas quem diz que o projeto foi ou não um sucesso? Segundo Thomas A. Stewart
citado por Kerzner (2006, p. 16).
17
Quando uma empresa deixa de ser definida por seus departamentos funcionais e se torna um portfólio de projetos e processos é mais fácil obter-se crédito por um sucesso. Os resultados logo aparecem e são óbvios. Da mesma forma, torna-se difícil jogar culpa de algum fracasso sobre “eles”, pois “eles” fazem, cada vez mais, parte de sua equipe multifuncional de projetos. (STEWART, 1997).
Segundo Valle (2007, p. 57) as características para um projeto ser considerado
bem sucedido ele deve produzir todas as entregas que foram nele planejadas, ele
deve completar esses objetivos dentro dos prazos estabelecidos previamente, deve
ser executado dentro do orçamento acordado e ter sido entregue com todas as
especificações funcionais, de performance e de qualidade. Esse projeto alcançou
todas as metas, objetivos, propósitos e finalmente, atingiu todas as expectativas das
partes interessadas, ou seja, os stakeholders.
Porém Kerzner (2006, p. 41) fala que o sucesso definido como a conclusão na
programação, no prazo, no custo e no nível de qualidade pré-estabelecido pelo
cliente é uma visão incompleta do sucesso. Afinal qualquer projeto poderá atingir o
sucesso com a interferência de gerente de projeto que usa sua força e repressão
para atingi-lo. Mas isso de maneira alguma significa que esse atingiu o sucesso
através da gestão de projetos.
A visão moderna, ainda segundo o mesmo autor, é formada por dois tipos de
fatores. Os primários que consistem em cumprir o prazo, o orçamento e a qualidade
e os secundários que consistem na aceitação do cliente, na referência pelo cliente
do trabalho de acompanhamento, do sucesso financeiro, superioridade técnica,
alinhamento do projeto, regulamentação pelas agências de regulamentação, saúde
e segurança, proteção ambiental, reputação da empresa, alinhamento dos
funcionários e conduta ética. Assim a “definição absoluta de sucesso será
visualizada quando o cliente estiver tão satisfeito com os resultados que permitirá a
utilização de seu nome como referência”. (KERZNER, 2006, p. 42)
Os principais motivos para o insucesso de um projeto são a falta de
alinhamento da organização, falta de um escopo realista, falta de infraestrutura para
o projeto, falta de uma metodologia formal de gerenciamento de projeto, falta de
estimativas confiáveis e a falta de habilidade dos recursos humanos (VALLE,
PEREIRA, et al., 2007). Quando todos os envolvidos no projeto não têm a mesma
visão do mesmo, esse projeto está fadado ao fracasso. Só será possível alcançar o
18
sucesso se esse for o objetivo que todos os envolvidos. Da mesma forma quanto
maior for o projeto, mais difícil será para conduzi-lo, assim haverá um aumento das
chances de insucesso. É uma prática comum dividir projetos grandes em projetos
menores independentes, para melhor gerenciá-los.
A infraestrutura pode ser um fator crucial para o sucesso do projeto, isso inclui,
por exemplo, o investimento em softwares que auxiliam na execução do projeto. Por
exemplo, não há como pensar em conduzir um projeto estrutural de um edifício sem
o auxilio de programas de cálculo estrutural.
Muitos gerentes de projeto conduzem seus projetos sem uma metodologia
consagrada, eles trabalham de forma empírica sem fundamentação em nenhuma
metodologia determinada ou sistematicamente organizada. Acham que sempre deu
certo da maneira que conduziram seus projetos e não procuram conhecer as boas
práticas reconhecidas na atualidade.
As estimativas de projetos são um grande gargalo no gerenciamento de
projetos. Muitas empresas não possuem um banco de informações dos projetos
anteriores. Assim não se tem como fazer uma estimativa precisa dos prazos e
custos, que é exigida para o uso de técnica como o PERT (Program Evaluation and
Review Technique), por exemplo. Esse banco de informações é especialmente
importante principalmente quando se pretende participar de concorrências públicas.
A falta de habilidade dos recursos humanos que não atendem as necessidades
do projeto por uma porção de fatores como a formação técnica da equipe, a
disponibilidade no mercado de profissionais qualificados, treinamento prévio para os
nivelamentos dos recursos humanos entre outros. O gerente de projeto é
responsável pela condução da equipe e para isso ele precisa ter uma série de
habilidades muito particulares, como conduzir as comunicações do projeto, isto é, a
troca de informações. Ele que influenciará a equipe envolvida no projeto, que terá
um papel de liderança, de motivação e, por vezes, terá que realizar negociações e
administrar conflitos dentro e fora da equipe e ainda revolvendo problemas que
podem aparecer durante todas as fases do projeto.
O gerente de projetos é responsável por reunir as informações e as transformar
em resultados segundo Thomas A. Stewart citado por Harold Kerzner (2006, p. 16).
19
Stewart chega a comparar os velhos gerentes a dinossauros que agem pela força e
compara os gerentes de projeto a mamíferos superiores que cada vez mais
precisam viver pela sua inteligência ao invés de sua força. O gerente de projeto é
cada vez mais um gestor integrado, muitas vezes multidisciplinar, do que um
especialista técnico.
Entre as diversas atribuições do gerente de projeto estão a identificação das
necessidades dos projetos, estabelecimento dos objetivos, claros e mensuráveis,
atender as expectativas de todos os Stakeholders, a fazer o sutil equilíbrio entre a
qualidade, o escopo, o tempo e o custo.
Porém segundo Barcaui (2010) a evolução de uma organização não tão trivial,
sendo necessária uma adaptação e muitas vezes uma mudança no modo de
operacionalizar e de pensar para se poder evoluir. Cada novo passo ao encontro da
mudança, e cada nova mudança um novo projeto. Mas porque há tanta resistência
para a mudança?
Primeiramente, o porquê mudar o modo de conduzir os projetos. Quando a
gestão de projetos é combinada com o gerenciamento de mudanças (item que
falaremos mais a frente) a organização será capaz de reagir às mudanças com a
rapidez exigida pelo cliente, reduzirá o impacto da mudança no orçamento e na
programação do projeto, aumentará a adição de valores em nome dos clientes, terá
boas relações com os clientes o que os deixará mais satisfeitos. E ainda permitirá
uma tomada de decisão mais rápida e maximizará iniciativas nas organizações,
privilegiando o foco e a comunicação aberta.
Segundo Harold Kerzner (2006, p. 15): “O desafio para quem não quer ser
apenas uma empresa no mercado está em gerenciar atividades nunca realizadas no
passado e que podem jamais vir a se repetir no futuro.” Mais uma vez a pergunta
retorna, por que há tanta resistência a mudança das metodologias adotadas?
Um fato que contribuiu para a resistência a mudança foi o fato da preferência
da alta gerência em manter o status quo por interesses próprios ou dos executivos e
não pelo bem da empresa. Existe fatores que influenciam a empresa aceitar a
gestão de projetos. Primeiro internamente quando a alta gerência passa a descobrir
os benefícios do gerenciamento de projeto à medida que monitora os resultados
20
obtidos. Segundo fatores externos como a concorrência, clientes esperam baixo
custo e a utilização das metodologias de gerenciamento em seu projeto. Padrões de
qualidades, os clientes estão cada vez mais exigentes quanto à qualidade e a
inexistência de falha. Resultados financeiros, o cliente deseja baixar os custos para
maximizar os lucros. Preocupações Legais, hoje em dia principalmente as
ambientais. Fatores tecnológicos, como a tecnologia avançada o cliente espera um
menor preço. As preocupações sociais, hoje as empresas se preocupam com seu
empregado e quer um planejamento bem feito para evitar a realização de horas
extras. Fatores políticos, já que empresas globais precisam estar alinhadas em todo
o mundo. Pressão econômica, hoje há uma necessidade e uma pressão para
realizar os mesmos trabalhos em menos tempo. Preocupações com os acionistas,
se a empresa for de capital aberto os acionistas fazem pressão para diminuição dos
custos.
Vê-se que existe uma pressão competitiva para a adoção de metodologias de
Gerenciamento de Projeto. Nesse trabalho focaremos na metodologia do Project
Management Institute (PMI) e na Metodologia de Gerenciamento Ágil de Projetos
(APM – Agile Project Manegement). Mas vale salientar que existem outras
instituições de gerenciamento de projetos como a International Organization for
Standartdization (ISO), International Electrotechnical Commission (IEC), e a
International Project Management Association (IPMA).
O PMI foi fundado em 1969 e é sediado na Filadélfia nos Estados Unidos, ele é
uma das principais associações de gerenciamento de projeto e atualmente conta
com mais de 500mil associados6. Fez seu primeiro congresso em 1970 e no mesmo
ano abriu sua primeira sede regional. Em 1980 foi criado um código de ética para a
profissão e uma certificação internacional o Project Management Professional (PMP)
e hoje consta cerca 400 mil certificados emitidos até o final de 20107.
6 Site http://www.pmi.org/About-Us.aspx. Acesso: 12 jun. 2011
7 Site: http://www.pmi.org/GLOBALS/~/media/Files/PDF/Certification/PMI235%20Credentials
Brazil222.ashx. Acesso: 12 jun. 2011
21
Foi desenvolvido pelo PMI e já se encontra em sua 4ª edição o A Guide to the
Project management body of knowledge (PMBOK), que é um guia que tem como
objetivo identificar o subconjunto do conjunto de conhecimentos em gerenciamento
de projetos que é amplamente reconhecido como boa prática. Mas o que vem a ser
uma “boa prática”.
Segundo Kerzner (2006, p. 56) boas práticas, ou melhores práticas são
atividades ou processos reutilizáveis que continuamente agregam valor ao produto
final dos projetos e podem aumentar a probabilidade de sucesso do mesmo. As
melhores práticas podem acontecer em qualquer lugar, nas relações de trabalho, no
desenho dos modelos ou na forma como as metodologias de gestão são utilizadas.
Porém o que funciona bem como boa prática para uma empresa ou projeto não
necessariamente funcionará para outro. Por isso mesmo um gerente de projeto
deverá saber quando os processos listados no PMBOK são aplicáveis em seu
projeto.
O PMBOK descreve 44 processos que estão divididos em cinco grupos, esses
cinco podem ser repetidos muitas vezes ao longo de um projeto, são eles: Iniciação,
Planejamento, Execução, Monitoramento e Controle e Encerramento.
Na iniciação se formaliza a existência do projeto na organização, definem-se o
seu escopo, objetivos e nomeia o gerente de projeto e finalmente faz-se a
autorização para contratação dos recursos. No planejamento decide-se qual o
melhor grau de precisão que será detalhada a declaração de escopo, como deve ser
feito o planejamento do projeto e define-se a linha base do projeto. Na execução
tem-se a produção de entregas pela integração das pessoas da organização e
recursos materiais. No monitoramento e controle há a conferencia de todos os
resultados da execução da linha de base e praticam-se as ações corretivas.
Finalmente há o encerramento formal do projeto, faz-se o aceite dos resultados pelo
cliente, fazem-se os encerramentos de contratos e desmobiliza a equipe. Não
podemos confundi esses processos como sendo as fases desse projeto.
Os processos também podem ser divididos em nove áreas de conhecimento
que são conjuntos de processos agrupados por requisito de conhecimento que são
tratados como um conjunto técnico comum. São elas:
22
• Integração do Gerenciamento de Projeto;
• Gerenciamento de escopo do projeto;
• Gerenciamento de tempo do projeto;
• Gerenciamento de custo do projeto;
• Gerenciamento da qualidade do projeto;
• Gerenciamento de recursos humanos do projeto;
• Gerenciamento de riscos do projeto;
• Gerenciamento de comunicação do projeto;
• Gerenciamento de aquisições do projeto;
A figura a seguir foi adaptada do PMBOK, mostra a divisão dos 44 processos
entre os grupos e áreas de conhecimento.
Quadro 1 – Os processos do PMBOK
Processos de Área de conhecimento
Grupo de processos de gerenciamento de projetos
Grupo de processos de
iniciação
Grupo de processos de planejamento
Grupo de processos de
execução
Grupo de processos de
monitoramento e controle
Grupo de processos de encerramento
Integração de gerenciamento de
projeto
4.1 Desenvolver o termo de abertura
4.2 Desenvolver o plano de
gerenciamento de projetos
4.3 Orientar e gerenciar a
execução do projeto
4.4 Monitorar e controlar o trabalho
do projeto
4.5 Realizar o controle integrado
de mudanças
4.6 Encerrar o Projeto
Gerenciamento do escopo do projeto
5.1 Coletar Requisitos
5.2 Definir o escopo
5.3 Criar a EAP
5.4 Verificar o escopo
5.5 Controlar o escopo
Gerenciamento de tempo do projeto
6.1 Definir atividades
6.2 Sequenciar as atividades
6.3 Estimar recursos para as
atividades
6.4 Estimar a duração das atividades
6.5 Desenvolver o cronograma
6.6 Controlar o cronograma
Gerenciamento de custos do projeto
7.1 Estimar os custos
7.2 Determinar o orçamento
7.3 Controlar os
custos
23
Processos de Área de conhecimento
Grupo de processos de gerenciamento de projetos
Grupo de processos de
iniciação
Grupo de processos de planejamento
Grupo de processos de
execução
Grupo de processos de
monitoramento e controle
Grupo de processos de encerramento
Gerenciamento da qualidade do
projeto 8.1 Planejar a
qualidade
8.2 Realizar a garantia da qualidade
8.3 Realizar o controle da qualidade
Gerenciamento de recursos humanos
do projeto
9.1 Desenvolver o plano de recursos
humanos
9.2 Contratar a equipe do projeto
9.3 Desenvolver a equipe do projeto
9.4 Gerenciar a equipe do projeto
Gerenciamento das comunicações do
projeto
10.1 Identificar os stakeholders
10.2 Planejar as comunicações
10.3 Distribuir informações
10.4 Gerenciar as expectativas dos
stakeholders
10.5 Reportar o desempenho
Gerenciamento dos riscos do projeto
11.1 Planejar o gerenciamento de
riscos
11.2 Identificar os riscos
11.3 Realizar análise qualitativa
dos riscos
11.4 Realizar a análise quantitativa
dos riscos
11.5 Planejar as respostas aos riscos
11.6 Monitorar e controlar os riscos
Gerenciamento de aquisições do
projeto. 12.1 Planejar as
aquisições 12.2 Conduzir as
aquisições 12.3 Administrar as
aquisições 12.4 Encerrar as
Aquisições
Fonte: PMI (2008, p.43)
Nesse trabalho iremos focar uma área específica dentro desses processos que
trata do Gerenciamento de Mudança em projetos de engenharia. As mudanças
durante a execução do trabalho, em relação ao que foi planejado para o projeto são
bastante comuns e esperadas (XAVIER, VIVACQUA, et al., 2009). Esses mesmos
autores citam que essas mudanças não são necessariamente negativas para os
projetos, mas seu gerenciamento é fundamental, pois o excesso, ou mesmo uma
única mudança crítica pode causar um impacto significativo no cronograma, no custo
e na qualidade do projeto se não for devidamente avaliada ou controlada.
No próximo capítulo iremos estudar como duas metodologias de
gerenciamento de projeto lidam com o gerenciamento de mudanças em projetos. A
24
primeira metodologia é a apresentada pelo PMI através do Guia do conhecimento
em Gerenciamento de Projeto (PMI, 2008) e a segunda é o chamado Gerenciamento
Ágil de Projetos que tem como base os princípios do Manifesto Ágil (Agile
Manifesto8) que é voltado para o gerenciamento de projetos inovadores.
8 Site: http://agilemanifesto.org/ Acesso: 24 jul. 2011
25
3. METODOLOGIA DE GERENCIAMENTO DE MUDANÇAS
Um fator crítico para o sucesso dos projetos é uma condução estruturada do
processo de solicitação das mudanças, com a utilização de um procedimento formal,
previamente definido e documentado (XAVIER, 2009). Segundo esse mesmo autor
as principais origens das alterações são: Erros ou omissões na avaliação inicial de
como atingir a meta do projeto; novas informações acerca do produto do projeto; um
novo mandato (mudança do patrocinador, cliente, usuário ou gerente de projeto);
mudanças no negócio ou no ambiente em que a empresa está inserida;
implementação de um plano de contingência demandado após analise de riscos;
entusiasmo da equipe; requisitos esperados pelo cliente ou patrocinador que não
foram declarados por serem considerados óbvios.
Mauro Afonso Soutille cita como origens das solicitações de mudanças: faltas
de questionamentos sobre uma solicitação inicial do cliente pode gerar uma má
definição do projeto; uma definição pobre, insuficiente, sobre as necessidades do
cliente e os requisitos, funcionais e técnicos, do projeto; pouca ou nenhuma
comunicação com o cliente e seus usuários ao longo do desenvolvimento do projeto;
mudanças na percepção do cliente sobre a sua real necessidade mudanças na visão
dos especialistas sobre o que pode ou o que deve ser oferecido ao cliente;
mudanças nas condições políticas, econômicas, sociais, técnicas e mercadológicas
que cercam e influenciam o projeto; mudanças sugeridas pelo gerente do projeto
para fazer frente às mudanças nas restrições impostas aos projetos; mudanças
propostas pelo gerente do projeto em função da não confirmação de premissas
assumidas no inicio do projeto; ajustes propostos pelo patrocinador do projeto
oriundos de alguma mudança na forma de relacionamento comercial com o cliente;
troca de representante, técnico ou comercial, do cliente; evolução tecnologia que
exija a aplicação de novos recursos e caprichos pessoais, do cliente ou mesmo dos
especialistas ou do gerente do projeto (SOTILLE, MENEZES, et al., 2010).
Como foi falado no final do capítulo anterior, as mudanças não são
necessariamente negativas, mas precisam ser avaliadas e controladas através de
um processo formal, de modo avaliar os impactos causados pelas mudanças.
26
Mudanças programadas requerem novas estimativas ou mesmo previsões de custo,
modificações na sequência das atividades, nos prazos, nas necessidades de
recursos, na análise de alternativas de resposta aos riscos, ou em outros ajustes no
Plano de Gerenciamento de Projeto (XAVIER, VIVACQUA, et al., 2009).
Durante a execução do projeto é comum a necessidade de serem efetuadas
mudança em relação ao escopo planejado constante da EAP e seus dicionários
(XAVIER, 2009). O escopo é um dos elementos mais suscetíveis à mudança ao
longo do desenvolvimento de um projeto cabe ao gerente de projeto criar
mecanismos que funcionem ao longo do ciclo de vida do projeto para registro das
solicitações de mudanças, garantir o fluxo de informações e suportar o processo de
tomada de decisão (SOTILLE, MENEZES, et al., 2010).
Segundo Kerzner (2006, p. 26) a gestão de projetos associada ao
gerenciamento de mudanças pode permitir entre outras coisas a capacidade de
reagir com rapidez às mudanças exigidas pelos clientes e a redução do impacto da
mudança no orçamento e na programação. Embora pode ser visto como algo muito
burocrático o gerenciamento de mudanças dá algumas garantias importantes ao
gerenciamento de projetos, tanto para o cliente quanto para o responsável do
projeto. Essas garantias podem ser: a garantia da origem da solicitação de
mudança; à necessidade de condução da mudança; ao registro dos fatos geradores;
à definição dos envolvidos em sua análise; à memória de cálculo empregada para
avaliar o custo benefício, ao retorno das mudanças, aos recursos envolvidos, ao
prazo necessário, às consequências sobre a qualidade e aos riscos agregados ao
projeto; à acumulação e ao registro de informações sobre as mudanças; à
distribuição dessas informações a todos os intervenientes necessários; à tomada de
decisão, favorável ou não, ou se sujeita a observações e finalmente à coleta das
assinaturas dos responsáveis (técnico, financeiro, legal, gerencial) dentro de suas
respectivas alçadas (SOTILLE, MENEZES, et al., 2010).
O gerenciamento de mudanças faz parte do controle de escopo que é
responsável por monitorar o status de escopo e controlar suas mudanças de forma
organizada, deve receber os pedidos de alterações e avaliar o seu impacto no
próprio projeto, obter sua autorização e se autorizadas refletir as mudanças
solicitadas na linha base do projeto. Esse controle deve influenciar os fatores que
27
geram as alterações do escopo para assegurar que, ao serem solicitadas, haja
concordância a respeito delas, detectar que uma alteração de escopo ocorreu e
administrar as alterações quando ocorrerem (XAVIER, 2009).
As empresas utilizam a gestão de mudança para controlar mudanças no
escopo do projeto tanto as geradas internamente quanto aquelas solicitadas pelos
clientes. Muitas dessas empresas criam comitês específicos para tratarem dessas
solicitações de mudanças (KERZNER, 2006). Esse comitê é responsável pela
aprovação ou rejeição das solicitações de mudanças. Essa reponsabilidade é
claramente definida dentro dos procedimentos de controle de configuração e
mudanças e são aceitos pelas partes interessadas apropriadas. Muitas
organizações de grande porte possuem uma estrutura de comitês em vários níveis,
dividindo as responsabilidades entre os mesmos (PMI, 2008).
Possuindo ou não esse comitê, as empresas têm que ter em mente as
seguintes perguntas: Qual é o custo da mudança? Qual é o impacto da mudança
nas etapas do projeto? Qual o valor agregado que esta mudança representa para o
cliente ou usuário final? (KERZNER, 2006).
Segundo o mesmo autor quando o cliente desencadeia o processo de
exigência de mudança, o gerente de projeto deve ser capaz de prever de imediato o
impacto da mudança na programação, segurança, custo e desempenho técnico.
Esta informação dever ser transmitida imediatamente ao cliente, especialmente
quando, em decorrência de um estágio avançado no projeto, não é mais possível
nenhuma alteração do projeto. Colocar o cliente a par da maneira pela qual a sua
metodologia se concretiza é fundamental para convencer o cliente da utilidade de
suas recomendações durante o processo de mudança de escopo.
Brad Ruzicka, gerente consultor sênior do StoneBridge Group, citado por
Kerzner (2006, p. 343) fala que empresas de consultoria devem ter seus próprios
padrões de controle de mudanças de escopo e também devem conhecer o processo
de controle de mudança utilizado por seus clientes. Ele explica:
28
Como empresa de consultoria, a habilidade de controlar mudanças de escopo é extremamente importante uma vez que, frequentemente, nos solicitam orçamentos de nossos serviços no inicio de um projeto. Como resultado, nossa abordagem padrão é definir escopo, abordagem geral, objetivos e expectativas de orçamento em nossa Declaração de Trabalho e obter a concordância do Responsável pelo Projeto com base em exemplos de projetos semelhantes em que nossa empresa atuou no passado. Então concordamos que qualquer mudança substancial no decorrer do projeto deverá ocorrer sob concordância do StoneBridge Group e o responsável, quando produziremos uma Declaração de Trabalho revisada.
Pensemos numa situação aonde o Gerente de Projetos esta conduzindo um
projeto de uma edifício que tem uma data de entrega fixa. Onde a partir de dessa
data se o empreendimento não for entregue poderão ocorrer multas e processos
judiciais que poderão acarretar em um prejuízo enorme. O Gerente de Projeto vê
seus chefes nas empresas como seus clientes onde ele se compromete a entregar o
projeto no prazo. Estes já encaram como seus clientes os moradores que se não
receberem seus apartamentos no prazo ficaram insatisfeitos e cobraram na justiça
os seus direitos. Pode-se imaginar que se esse empreendimento não for entregue
haverá uma caça ao responsável em todos os níveis. Analisando esse exemplo
veremos que há uma relação muito forte entre gerenciamento de mudanças e o
gerenciamento de risco.
De fato, o gerenciamento de riscos e a gestão de mudanças funcionam
paralelamente. Os riscos geram mudanças que, por sua vez, criam novos riscos. Em
empresas com excelência em gestão de projetos, o gerenciamento de riscos e a
gestão de mudanças desenvolvem-se continuamente ao longo de todo o ciclo de
vida de um projeto. O impacto sobre a qualidade, o custo e a atualidade do produto
é constantemente atualizado e relatado à administração com a maior presteza
possível. O objetivo é sempre minimizar o número e as proporções das surpresas
(KERZNER, 2006).
Depois dessa visão geral sobre gerenciamento de mudanças em projetos
vamos estudar como duas metodologias de gerenciamento de projetos lidam com o
gerenciamento de mudanças em projetos. A primeira metodologia é a apresenta pelo
PMI através do Guia do conhecimento em Gerenciamento de Projeto (PMI, 2008) e a
segunda é o chamado Gerenciamento Ágil de Projetos.
29
Metodologia PMI (Project Management Institute)
Na metodologia do PMI quem é responsável pelo Gerenciamento de Mudanças
são os processos da área de conhecimento de Integração. Esses processos são
responsáveis por identificar, definir, combinar, unificar e coordenar os vários
processos e atividades dos grupos de processo de gerenciamento. Eles requerem
que sejam feitas escolhas sobre alocação de recursos, concessões entre objetivos e
alternativas conflitantes e particularmente o gerenciamento de dependências mútuas
entre as áreas de conhecimento (PMI, 2008).
Vale que ressaltar que o próprio guia PMBOK alerta sobre o cuidado de serem
usados somente os processos necessários para o gerenciamento do projeto. O
gerente de projeto e a equipe devem sempre discutir todos os processos para
determinar o nível de execução de cada processo para cada projeto. De uma forma
reduzida o grupo de processos de planejamento fornece ao grupo de processos de
execução um plano de gerenciamento do projeto documentado no início do projeto,
facilitando as atualizações ao plano de gerenciamento, se mudanças ocorrem
durante o progresso do mesmo (PMI, 2008).
Para executar o Gerenciamento de Mudanças ele deve ser primeiramente
planejá-lo, ou seja, planejar o Controle Integrado de Mudanças. Isso acontece no
processo “Desenvolver o Plano de Gerenciamento do Projeto”. Nesse processo
define-se como o projeto será executado, monitorado e controlado e como ele será
encerrado. Esse plano será elaborado progressivamente através de atualizações,
controladas e aprovadas pelo processo “Realizar o Controle Integrado de Mudança”
(PMI, 2008). Como veremos mais a frente este último processo será o responsável
por implementar as mudanças ao plano de gerenciamento do projeto. Segundo
Xavier (2009, p. 202) as organizações devem definir um procedimento em que
conste a politica de gerenciamento que cobrirá o processo de solicitação de
alteração e a informação requerida para processar cada solicitação, o processo
usado para análise dos impactos no projeto e o grupo da organização que autoriza
formalmente as alterações do escopo no projeto.
30
As entradas para o processo de “Desenvolver o Plano de Projeto” são o Termo
de Abertura do Projeto (TAP), saídas dos processos de planejamentos, fatores
ambientais da empresa e os ativos de processos organizacionais. O TAP que
formalmente autoriza um projeto ou fase e documenta os requisitos iniciais que
satisfaçam as necessidades e expectativas das partes interessadas. Nele o gerente
de projeto é identificado (PMI, 2008). Em algumas organizações o Termo de
abertura do projeto transformou-se em um documento interno pelo qual a empresa
reconhece e comunica o escopo aprovado do projeto aos gerentes funcionais, ou de
linha, e seu pessoal, como uma espécie de “contrato” entre o gerente e a
organização (XAVIER, 2009). Segundo o mesmo autor há outros nomes para esse
documento: termo de referência do projeto; documentos de autorização do projeto;
documento inicial do projeto; documento de abertura do projeto; autorização de
início do projeto; proposta de projeto aprovada; carta do projeto. O TAP deve conter
no mínimo a justificativa do projeto, o escopo ou visão do cliente, a designação do
gerente de projeto e sua autoridade, as restrições e as premissas do projeto.
As saídas dos processos de planejamento são as saídas dos processos de
planejamento das demais áreas de conhecimentos (escopo, tempo, custo,
qualidade, recursos humanos, aquisições, comunicações e riscos), e suas
atualizações quando houver algum replanejamento. Os fatores ambientais da
empresa é qualquer um dos fatores ambientais externos ou organizacionais internos
que cercam ou influenciam o sucesso do projeto, incluem a cultura, a estrutura
organizacional, infraestrutura, recursos existentes, bancos de dados comerciais,
condições de mercado e software ou sistema de informação de Gerenciamento de
Projeto (SIGP). Os ativos de processos organizacionais é qualquer um ou todos os
ativos relacionados aos processos das organizações que podem influenciar o
sucesso do projeto, incluem planos formais e informais, políticas, procedimentos e
diretrizes, também incluem os conhecimentos organizacionais como as lições
aprendidas e informações históricas. Relacionado com o Gerenciamento de
Mudanças podemos citar os procedimentos de controle de mudanças, passo para
modificações dos padrões, políticas, planos e procedimentos oficiais da empresa e
quaisquer documentos do projeto que serão modificados e como essas mudanças
serão aprovadas e avaliadas (PMI, 2008).
31
Dentro das ferramentas e técnicas desses processos o PMBOK (PMI, 2008)
descreve uma única, a opinião especializada que ajudará o gerente de projeto a:
atender as necessidades do projeto; desenvolver os detalhes técnicos e de
gerenciamento; determinar recursos e níveis de habilidades necessárias para
executar o trabalho; determinar o nível de gerenciamento de configuração e
especialmente importante para o Gerenciamento de Mudanças; determinar quais
documentos do projeto estarão sujeitos ao processo formal de controle de
mudanças.
A principal saída desse processo é o Plano de Gerenciamento de Projeto, ele
integra e consolida todos os planos de gerenciamentos auxiliares e as linhas de
base dos processos de planejamento. Nesse plano deve estar integrado o ciclo de
vida do projeto, descrito como o trabalho será executado, o plano para completar os
objetivos do projeto, deve conter um plano de gerenciamento de configuração, deve
conter como a integralidade da linha de base da medição de desempenho, incluir as
necessidades e técnicas para as comunicações no projeto, e ligado ao
Gerenciamento de Mudanças o plano deve conter o Plano Integrado de
Gerenciamento de Mudanças que documenta como as mudanças serão monitoradas
e controladas.
Para Xavier et al. (2009, p. 109) o planejamento do Controle Integrado de
Mudanças tem como objetivo planejar como as mudanças no projeto poderão ser
solicitadas e como será feita a avaliação dessa solicitação, seu mecanismo de
aprovação e o respectivo reflexo no planejamento do projeto. Se uma mudança for
aprovada implicará em uma revisão nas linhas base do projeto.
As linhas de base incluem a linha de base do cronograma, desempenho de
custo, e do escopo. E finalmente o plano de gerenciamento de projetos incluem os
planos auxiliares: plano de gerenciamento de escopo, plano de gerenciamento dos
requisitos, plano de gerenciamento do cronograma, plano de gerenciamento dos
custos, plano de gerenciamento da qualidade, plano de melhorias no processo,
plano de gerenciamento dos recursos humanos, plano de gerenciamento das
comunicações, plano de gerenciamento dos riscos, plano de gerenciamento das
aquisições (PMI, 2008).
32
O próximo processo segundo o PMBOK (PMI, 2008) da área de conhecimento
de Integração é o “Orientar e Gerenciar a Execução do Projeto” sua função é
realizar o trabalho definido no plano de gerenciamento do projeto para atingir seus
objetivos. Suas atividades são: executar as atividades planejadas; criar as entregas
do projeto; formar, treinar e gerenciar a equipe; obter, gerenciar e usar recursos;
implementar padrões e métodos; estabelecer e gerenciar canais de comunicação;
gerenciar vendedores e fornecedores. Outras atividades desse processo que são
ligadas ao Gerenciamento de Mudanças podem ser citadas como: Gerar dados e
informações sobre o andamento do projeto, eles serão importantes para que o
processo “Monitorar e Controlar o Trabalho do Projeto” possa fazer um comparativo
com o planejado e analisar as necessidades de mudanças; Havendo necessidade
de mudanças, emitir as solicitações de mudança e adaptar as mudanças aprovadas;
gerenciar os riscos, inclusive os gerados pelas mudanças, e implementar atividades
de respostas; coletar e documentar lições aprendidas e implementar melhorias.
Porém, vale salientar que diversos autores (SOTILLE, MENEZES, et al., 2010;
XAVIER, 2009; XAVIER, VIVACQUA, et al., 2009) citam as lições aprendidas em
seus capítulos de controle de projeto.
Para Soutille (2010, p. 136) todas as mudanças devem ser documentadas e
comunicadas e um processo de análise posterior dessas informações pode gerar um
resultados positivo e estruturado que seria as lições aprendidas. Para o mesmo
autor as lições aprendidas geram um grande histórico de projeto que servirão como
base de orientação em decisões futuras do mesmo projeto ou de projetos futuros
das organização. Como as mudanças no projeto são as maiores causas de atrasos
em projetos, é fundamental um processo de documentação do que ocasionou as
mudanças dentro do projeto, as razões das ações corretivas tomadas e outros tipos
de lições aprendidas (XAVIER, 2009).
Segundo o PMBOK (PMI, 2008) o processo “Orientar e Gerenciar a Execução
do Projeto” também requer na implementação de mudanças aprovadas, ações
corretivas para que o desempenho futuro do projeto fique de acordo com o plano de
gerenciamento, ações preventivas para realização de uma atividade para reduzir a
probabilidade negativa associada aos riscos do projeto e reparo de defeito que
consiste na identificação de um defeito e sua recomendação de reparo do defeito ou
33
mesmo substituir completamente o componente. Vale lembrar que todas essas
ações devem ser documentadas. As mudanças aprovadas e documentadas também
podem ampliar ou limitar o escopo, podem modificar políticas, planos de
gerenciamento de projeto, procedimentos, custos e cronogramas.
Para Xavier (2009, p. 206), no caso de gerenciamento de escopo, deve-se
identificar as causas das solicitações de mudanças do escopo para influenciar que
elas ocorram o menor número de vezes possível, e para que elas possam ser
identificadas o mais breve possível.
As solicitações de mudanças podem ser saídas do processo “Orientar e
Gerenciar a Execução do Projeto”. Quando questões são encontradas durante a
execução do projeto, solicitações de mudança são emitidas e podem modificar
escopo, custo, cronograma, qualidade, politicas ou procedimentos do projeto. Além
de poder incluir ações corretivas, ações preventivas, reparo de defeitos as
mudanças podem conter atualizações das documentações formalmente controladas,
planos e documentos de modo a refletir as modificações que ocorreram (PMI, 2008).
Também segundo o PMBOK (PMI, 2008) cabe ao gerente de projetos junto
com sua equipe a orientação para o desempenho das atividades do projeto e o
gerenciamento de todas as interfaces técnicas e organizacionais que existem dentro
dos projetos. A situação atual do projeto, as entregas feitas, o desempenho geral do
projetos devem alimentar os relatórios de desempenho (processo “Reportar
Desempenho”) e este vai fornecer as informações que servirão de entrada para o
processo da área de conhecimento de Integração “Monitorar e Controlar o Trabalho
do Projeto”
O processo “Monitorar e Controlar o Trabalho do Projeto” é responsável pelo
acompanhamento, revisão e ajuste do progresso para atender aos objetivos do
projeto, definidos pelo plano de gerenciamento. Ele coleta, mede e distribuir as
informações sobre o andamento do projeto e também avalia as medições e
tendências para efetuar melhorias nos processos através de relatórios de
desempenho. As atividades desse processo incluem: comparação do desempenho
real em relação ao planejado; avaliação do desempenho para decidir e recomendar
ações corretivas e preventivas; identificação e analise de novos riscos e
34
monitoramento de riscos existentes; manutenção de uma base de informações do
projeto; fornecimento de informações para a elaboração de relatórios de
desempenho do projeto; fornecimento de previsões sobre o projeto e para o
Gerenciamento de Mudanças, o monitoramento da execução das mudanças
aprovadas no processo da área de conhecimento de Integração “Realizar o Controle
Integrado de Mudança” (PMI, 2008).
O gerente de projeto é, em primeira instância, o grande responsável pela
entrega e pelo monitoramento dos elementos de escopo do projeto (SOTILLE,
MENEZES, et al., 2010). Verificar o impacto das mudanças é muito importante para
o controle de mudanças do escopo. Quando fazemos o Plano de Gerenciamento do
Projeto, as estimativas de custo e tempo são baseadas em informações disponíveis
em arquivos de projetos, estimativas em bases de dados comerciais, conhecimentos
da equipe do projeto e consulta com fornecedores (XAVIER, 2009).
Podem-se usar essas mesmas fontes para estimar os impactos das mudanças.
Com relação aos impactos de prazo de conclusão do projeto, deve-se atentar se a
atividade impactada pertence ao caminho crítico do projeto. Quando isso acontece
quase sempre acontecem atrasos no projeto, já quando a atividade não está no
caminho crítico, as alterações de prazo podem não impactar no prazo final do
projeto, ou mesmo impactar minimamente. Lembrando que quando acontecem
alterações de tempo, o próprio caminho crítico pode alterar (XAVIER, 2009).
O processo responsável pela revisão de todas as solicitações, aprovação e
gerenciamento de mudanças em entregas, ativos de processos organizacionais,
documentos de projeto e plano de gerenciamento é chamado de “Realizar o
Controle Integrado de Mudanças”. As entregas são mantidas através do
gerenciamento cuidadoso e continuo das mudanças, rejeitando-as ou aprovando-as,
garantindo que somente mudanças aprovadas são incorporadas na linha de base do
projeto (PMI, 2008). Para Xavier et al. (2009, p. 134) o Controle Integrado de
Mudanças é um processo responsável por, de forma organizada e controlada,
receber os pedidos de alterações, avaliar seu impacto no próprio projeto e em seus
projetos interdependentes, obter sua autorização por quem de direto, se autorizadas,
refletir as mudanças solicitadas na linha base do projeto.
35
Segundo o PMBOK (PMI, 2008) o processo “Realizar o Controle Integrado de
Mudanças” tem as seguintes atividades: influenciar os fatores que evitam o controle
integrado de mudanças; revisar, analisar e aprovar as solicitações de mudanças
imediatamente; gerenciar as mudanças aprovadas; manter a integridade das linhas
de base do projeto com a incorporação das mudanças; revisar, aprovar ou rejeitar
todas as ações corretivas e preventivas recomendadas; coordenar as mudanças
através de todo projeto; documentar os impactos das solicitações de mudanças.
As entradas para o processo “Realizar o Controle Integrado de Mudanças” são:
o plano de gerenciamento de projeto; as informações de desempenho da equipe
através de relatórios de desempenho; os fatores ambientais da empresa, onde se
destaca um sistema de informação de gerenciamento de projeto e um sistema de
coleta e distribuição de informação; os ativos de processos organizacionais, como os
procedimentos de controle de mudanças, procedimentos para a aprovação e
emissão de autorizações de mudanças, banco de dados para medição de
processos, arquivos de projetos anteriores e as bases de conhecimento de
gerenciamento de configuração (PMI, 2008).
As solicitações de mudança podem ser feitas por qualquer parte interessada do
projeto, podem ser verbais, porém sempre devem ser registradas. Deve ser
aprovada ou rejeitada por alguma autoridade dentro da equipe de gerenciamento do
projeto ou de organização externa (PMI, 2008). Elas devem conter a data do pedido
de solicitação, local, atividade ou fase do projeto de ocorrência da mudança, estado
de origem, antes da mudança, e estado de destino depois da mudança
implementada, o grau de importância da mudança e solicitante (SOTILLE,
MENEZES, et al., 2010). Esse pedido pode ser feito de forma informatiza com um
sistema específico ou mesmo de maneira mais limitada através de planilhas,
editores de texto e correio eletrônico. Todos, se possível, devem prover: formulários
eletrônicos de solicitação de alteração, que possam ser preenchidos por diferentes
participantes do processo; um banco de dados para armazenar e gerenciar esses
formulários; um modelo de alteração que possa ser preenchido com um fluxo de
trabalho predefinido, em que pessoas responsáveis em cada estágio do processo
saibam quem dirigirá a próxima atividade; transferências eletrônicas de formulários
entre pessoas com responsabilidades diferentes e notificação de correio eletrônico,
36
quando as atividades forem completadas (XAVIER, 2009). As solicitações de
mudanças são identificadas durante a execução do trabalho, elas devem seguir os
procedimentos determinados no Plano Integrado de Gerenciamento de Mudanças
estabelecidas no plano de gerenciamento de projeto (XAVIER, VIVACQUA, et al.,
2009).
Ao receber as solicitações de mudança deve-se: identificar a situação e o fator
gerado da mudança para definir as ações necessárias para efetivá-las; recursos que
devem ser aportados; aprazamentos para as mudanças, impacto da mudança sobre
o prazo do projeto; outros impactos possíveis e benefícios a serem obtidos com as
mudanças. Essas informações devem ser analisadas e vão servir de auxílio para a
tomada de decisão. Um fluxograma de informações deve ser feito para envolver as
partes interessadas no levantamento e no processo de analises da tomada de
decisão. Essa tomada de decisão deve ser seguida pela distribuição de informações
para todos os stakeholders a ela envolvidos (SOTILLE, MENEZES, et al., 2010).
Segundo o PMBOK (PMI, 2008) as ferramentas e técnicas do processo
“Realizar o Controle Integrado de Mudanças” são basicamente a opinião
especializada através de consultores, das partes interessadas, associações
profissionais, setores econômicos, especialistas no assunto e escritórios de projetos
(PMO). Outra técnica é Reuniões de Controle de Mudanças. Quando numa
organização existe um Comitê de Mudanças que é responsável pela reunião e
revisão das solicitações de mudança e aprovação ou rejeição dessas mudanças.
Quando aprovadas as solicitações de mudança requerem novas e revisadas
estimativas de custos, sequencias de atividades, datas de cronograma, requisitos de
recursos e análises alternativas de respostas aos riscos. Tais mudanças irão
requerer mudanças no plano de gerenciamento do projeto e em suas linhas de base
do projeto. O processo “Realizar o Controle Integrado de Mudança” gera as
seguintes saídas: atualizações do andamento de solicitações de mudança que será
executada pelo processo “Orientar e Gerenciar a Execução do Projeto”; atualizações
do plano de gerenciamento do projeto através das atualizações dos planos auxiliares
e linhas de base do projeto sujeitas a essas mudanças; atualizações dos
documentos do projeto incluindo o registro formal de solicitações de mudança e
quaisquer outros documentos do projeto como, por exemplo, as lições aprendidas.
37
Caso ela não seja aprovada ela é devolvida ao solicitante para o fornecimento de
informações adicionais. Ela pode ficar guardada e ser implementada futuramente
quando possível (PMI, 2008).
Segundo Xavier (2009, p. 205), as solicitações de alteração de escopo
normalmente resultam na alteração do plano de gerenciamento do projeto.
Especificamente falando de escopo, para avaliação dos impactos, alterações na
EAP ou alternativas de abordagem para o projeto devem ser simuladas. Raramente
não haverá uma inclusão de uma nova atividade ao escopo. Essas e outras
mudanças deverão ser implementadas nas linhas de base do projeto de modo a
refletir essas mudanças. Essa nova linha base será utilizada é a partir desse ponto,
para medições de desempenho do projeto.
O Controle Integrado de Mudanças fornece uma maneira padronizada, efetiva
e eficiente de gerenciar, de maneira centralizada, as mudanças e linhas de base
aprovadas dentro de um projeto. Seus principais objetivos são: estabelecer um
método evolutivo de identificar e solicitar as mudanças e avaliar o valor e a
efetividade dessas mudanças; proporcionar oportunidades de validar e aprimorar o
projeto continuamente; fornecer uma maneira eficiente para comunicar a equipe e as
partes interessadas de todas as mudanças aprovadas e rejeitadas (PMI, 2008).
Segundo Soutille (2010, p. 130), gerenciar as mudanças do escopo e das
outras áreas do projeto envolve a criação de mecanismos que sirvam como
obstáculos às tentativas de mudanças. É atribuição do gerente do projeto evitar ou
minimizar as mudanças de escopo que tantos impactos desagradáveis trazem ao
projeto, principalmente nas áreas de conhecimento de qualidade, recursos humanos,
prazos, custos e orçamentos.
Porém para projetos chamados inovadores onde as mudanças ocorrem
frequentemente esses processos podem se tornar demasiadamente burocráticos e
impraticáveis. Projetos inovadores são projetos com níveis maiores de riscos em que
correções e mudanças nas estratégias de condução não são apenas comuns, mas
necessárias para o projeto. A resposta para esse problema tem sido o surgimento de
novas teorias voltadas para esse tipo de projeto, como a teoria de Gerenciamento
Ágil de Projetos (do inglês, Agile Project Management – APM) (AMARAL,
38
CONFORTO, et al., 2011). No próximo item iremos nos aprofundar nos estudos
dessa teoria.
Metodologia APM (Agile Project Management)
Neste item todas as citações são do livro-texto Gerenciamento Ágil de Projetos
de Daniel Capaldo Amaral (AMARAL, CONFORTO, et al., 2011). Uma característica
dos projetos ágeis é seu teor de inovação e possuir em comum como característica
a incerteza, onde a equipe não pode prever com antecedência como ela será
executada. Haverá sempre uma grande margem de incerteza sobre recursos
necessários, prazos, riscos e demais áreas de conhecimentos do gerenciamento de
projetos.
Outra característica citada no livro-texto é a heterogeneidade das equipes,
onde estão envolvidos em um problema comum e há a necessidade de unir
diferentes especialistas dificultando o alinhamento dos objetivos. Os principais
desafios para os profissionais de gerenciamento de projetos inovadores são:
conduzir projetos com alto grau de incerteza; obter cooperação e coordenação
dentro das equipes de diferentes especialistas; realizar o projeto em ambientes
inovadores; envolver clientes e usuários no desenvolvimento do projeto; solucionar o
problema complexo indo além da solução tecnológica.
O termo Gerenciamento Ágil de Projeto (APM – Agile Project Management)
surgiu com um movimento iniciado pela comunidade internacional de
desenvolvimento de softwares. Ele surgiu com um novo enfoque de desenvolvimento
de softwares, calçado na agilidade, na flexibilidade, nas habilidades de comunicação
e na capacidade de oferecer novos produtos e serviços de valor ao mercado em
curtos períodos de tempo.
As definições sobre o Gerenciamento Ágil de Projetos se dividem basicamente
em dois grupos de autores. O primeiro grupo é formado por teorias propostas por
autores como Highsmith, Chin, Smith e DeCarlo que criam uma maneira
independente da área de domínio do projeto aplicáveis em projetos inovadores. Eles
citam os princípios e justificam as práticas ágeis, apresentam práticas e as
39
descrições de uma estrutura geral. O Segundo grupo de autores é formado por
teorias desenvolvidas especialmente para o desenvolvimento de software, são
teorias objetivas e direcionadas a aplicação com recomendações precisas.
Segundo Jim Highsmith citado no livro-texto, a agilidade seria a habilidade de
criar e responder a mudanças, a fim de obter lucro em um ambiente de negócio
turbulento. Alguns autores se uniram numa rede denominada Agile Alliance para
discutir alternativas aos processos gerenciais tradicionais, aprimorar e divulgar os
chamados Métodos Ágeis de Desenvolvimentos de Software. Publicaram o chamado
Manifesto para Desenvolvimento Ágil de Software, ou simplesmente Manifesto Ágil,
que falam em valorizar: os indivíduos e suas interações acima dos processos e
ferramentas; produtos funcionando acima de documentação excessivamente
detalhada; colaboração de clientes acima da negociação de contratos e respostas as
mudanças acima da execução de um plano.
Para Gary Chin citado no livro-texto o Gerenciamento Ágil de Projetos seria
então uma maneira de proceder em um conjunto de elementos em que essa
atividade é conduzida por meio de equipes autogerenciadas e utilizando técnicas de
gerenciamento simplificadas. Para Jim Highsmith citado no mesmo livro-texto o
Gerenciamento Ágil de Projetos é um conjunto de princípios, valores e práticas que
auxiliam a equipe de projetos a entregar produtos ou serviços de valor em um
ambiente de projetos desafiadores. Esse mesmo autor cita três pilares que
sustentam o APM: os valores e princípios que direcionam a aplicação do APM; O
modelo do processo proposto pelo autor e práticas específicas que caracterizam
seus princípios com foco em resultados. Para esses autores o APM seria uma
abordagem alternativa à tradicional de modo a permitir que as empresas sejam mais
efetivas no gerenciamento de projetos em ambientes de incertezas.
O autor DeCarlo citado no livro-texto trata do que ele chama de Extreme
Project Management que é definido como a:
Arte e ciência de facilitar e gerenciar o fluxo de pensamentos, emoções e interações para produzir resultados de valor em condições turbulentas e complexas que requerem velocidade, grandes mudanças, elevado nível de incertezas e estresse.
Numa abordagem aplicada a produtos, Smith citado no livro-texto usa o termo
“flexibilidade” ao invés de “agilidade” onde diz que “flexibilidade no desenvolvimento
40
de produtos significa a habilidade de fazer mudanças no produto, ou no processo de
desenvolvimento, mesmo em fase avançadas, sem afetar a qualidade e resultados”.
Há dois aspectos que podemos destacar nas teorias do APM, primeiramente a
abordagem que o gerenciamento ágil seria uma alternativa à tradicional específica
para a situação de equipes pequenas e autogerenciáveis e em segundo lugar o foco
da descrição está em princípios que diferenciariam a natureza das atividades de
gerenciamento de projeto e a responsabilidade pela execução.
Ao analisar o PMBOK vê-se que os processos foram estabelecidos para serem
aplicados a qualquer tipo de projeto, sendo necessária sua adaptação e adequação
aos diversos contextos de gerenciamento. Aparentemente o que se apresenta como
novidade na teoria de Gerenciamento Ágil de Projetos está nos aspectos como a
visão no lugar do escopo, a iteratividade e o foco no cliente. Esses aspectos serão
abordados mais profundamente à frente neste trabalho. Como citado pelo autor de
nosso livro-texto de referência, o problema está em equilibrar o nível correto de foco
nas pessoas ou foco nas práticas ou procedimentos.
Para o autor Augustine citado no livro-texto, retirando uma ideia de abordagem
alternativa ao tradicional, diz que o Gerenciamento Ágil de Projeto é:
[...]o trabalho de energizar, capacitar e habilitar a equipe de projeto para entregas mais rápidas e confiantes, de valor para o negócio, através de integração dos clientes num processo contínuo de aprendizado e adaptação das mudanças de acordo com suas necessidades e ambientes de negócios.
Analisando todas as definições citadas podemos identificar aspectos comuns
como: características como a flexibilidade e habilidade de absorver mudanças,
enfoque mais humanistas de autogestão no desenvolvimento da equipe de projeto,
no uso do aprendizado e da experiência dos indivíduos em detrimento da
valorização excessiva de técnicas e processos e a importância de uma visão única e
integrada do resultado final do projeto.
Foram definidos no manifesto ágil princípios para o Gerenciamento Ágil de
Projetos que seriam: prioridade pela satisfação do consumidor por meio de entregas
contínuas de valor e o mais breve possível; mudanças de requisitos são bem-vindas
mesmo em estágios avançados de desenvolvimento; entregar o produto funcionando
em curto período; desenvolvedores e gestores devem trabalhar diariamente em
41
conjunto; criar projetos com as pessoas motivadas; o método mais eficientes e eficaz
de transmitir informações em um projeto é por conversas diretas; produto
funcionando é a principal medida de progresso; processos ágeis promovem o
desenvolvimento sustentável; atenção contínua a excelência técnica; simplicidade,
deve-se deixar os trabalhos desnecessários de lado; os melhores requisitos surgem
de equipes que praticam a autogestão e em intervalos regulares a equipe deve
refletir sobre como se tornar mais eficaz.
Jim Highsmtih diz que as empresas precisam desenvolver uma cultura que
promova a adaptação para absorver mudanças, algumas poucas regras para
encorajar a auto-organização, combinada com a autogestão e colaboração interna e
interação entre todos os membros da comunidade do projeto. Para esse mesmo
autor os princípios para o Gerenciamento Ágil de Projetos são:
Entregar valor ao cliente: focar na inovação e adaptabilidade em vez de
eficiência e otimização, e concentra-se em entregas em vez de cumprimentos de
atividades.
Empregar entregas iterativas baseadas em características: desenvolvimento
iterativo significada que inicialmente existe a construção de uma versão parcial de
um produto ou projeto, depois a equipe expande essa versão por meio de
sucessivos e curtos períodos de desenvolvimento com a ajuda de revisões e
adaptações.
Buscar excelência técnica: projetos que buscam excelência técnica no
desenvolvimento de produtos possuem maiores chances de sucesso.
Encorajar a exploração: é função do gerente de projeto encorajar a
experimentação e o aprendizado por meio de sucessos e fracassos e ajudar a
equipe a compreender a visão a ser seguida.
Formar equipes adaptáveis: a meta principal da equipe é entregar
consistentemente a visão do produto que está prevista dentro do escopo do projeto.
O gerente de projeto é o responsável por formar equipes que sejam
auto-organizáveis e autodisciplinadas.
42
Simplificar: detalhar tarefas de um projeto ou diminuir excesso de
documentação inicial do projeto faz com que as pessoas interajam e,
consequentemente, cria um ambiente mais propício à inovação.
De acordo com o autor Augustine os princípios do Gerenciamento Ágil de
Projetos são: enfoque em entregas parciais; colocalização que consiste em todos os
membros da equipe de projeto trabalhar juntos em um mesmo ambiente, incluindo
representantes do cliente; definir um plano de iteração que consiste em priorizar as
entregas com a participação do cliente, onde são definidos recursos e o tempo
estimado para as entregas de acordo com as prioridades de negócios do cliente;
desenvolver equipes auto-organizadas.
Para Cohn, citado no livro-texto, os princípios do APM incluem: o trabalho
desenvolvido por uma equipe única; o trabalho desenvolvido em iterações curtas;
entregar algum valor em toda iteração; as prioridades do negócio; inspecionar e
adaptar constantemente. Na mesma linha de pensamento Boehm e Turner, citados
no mesmo livro-texto, falam em princípios como: ciclos iterativos curtos;
envolvimentos dos ativos dos clientes para definir e priorizar requisitos do produto;
desenvolvimento incremental; empregar equipes auto-organizadas e possuir umas
abordagem emergentes para os processos, em que os procedimentos e processos
evoluem durante o projeto em vez de serem predeterminados no inicio.
Como foi citada anteriormente neste trabalho a gestão de projetos associada
ao gerenciamento de mudanças pode permitir entre outras coisas a capacidade de
reagir com rapidez às mudanças exigidas pelos clientes e a redução do impacto da
mudança no orçamento e na programação (KERZNER, p. 26). Shenhar e Dvir,
citados no livro-texto Gerenciamento Ágil de Projeto (AMARAL, CONFORTO, et al.,
2011), trabalham com o termo “adaptive” para descrever uma abordagem para o
gerenciamento de projetos voltados para ambiente de negócios em que existe uma
alta complexidade e elevados níveis de incertezas. O quadro a seguir mostra uma
comparação proposta por esses autores das características tradicionais e a
abordagem que eles chamam de adaptativas:
43
Quadro 2 – Diferenças entre uma abordagem tradicional e uma adaptável
Abordagem Tradicional Adaptável
Metas do Projeto Enfoque na finalização do projeto no
tempo, custo e requisitos de qualidade.
Enfoque nos resultados do negócio, atingir múltiplos critérios de sucesso.
Plano de Projeto
Uma coleção de atividades executados como planejado para atender à restrição tripla(tempo,
custo e qualidade).
Uma organização e o processo para atingir as metas esperadas e os
resultados para o negócio.
Planejamento Realizado uma vez no início do
projeto. Realizado no início e reavaliado sempre
que necessário.
Abordagem gerencial
Rígida, com foco no plano inicial. Flexível, variável, adaptável.
Trabalho/Execução Previsível, mensurável, linear,
simples. Imprevisível, não mensurável, não
linear, complexo.
Influência da organização
Mínima, imparcial a partir do kick-off do projeto.
Afeta o projeto ao longo de sua execução.
Controle do projeto Identificar desvios do plano inicial e
corrigir o trabalho para seguir o plano.
Identificar mudanças no ambiente e ajustar o plano adequadamente.
Aplicação da metodologia
Aplicação genérica e igualitária em todos os projetos.
Adaptação do processo, dependendo do tipo de projeto.
Estilo de gerenciamento
Um modelo atende a todos os tipos de projetos.
Abordagem adaptativa, um único modelo não atende a todos os tipos de
projetos.
Fonte: Retirado do livro Gerenciamento Ágil de Projetos (AMARAL, CONFORTO, et al., 2011)
Daniel Amaral et al. (2011, p. 21) apresenta um resumos desses princípios
para caracterizar o Gerenciamento Ágil de Projetos, são eles:
• Aplicar técnicas simples e visuais de gerenciamento (simplicidade);
• Flexibilidade do processo para absorver mudanças no projeto;
• Buscar a excelência técnica;
• Agregar valor para o cliente e para a equipe de projeto;
• Utilizar o conceito de iterações e entregas parciais;
• Promover a autogestão e a auto-organização;
• Encorajar a tomada de decisão participativa;
44
• Encorajar a inovação e a criatividade; e
• Promover a interação e a comunicação entre os membros da equipe de
projetos.
Segundo o mesmo autor o Gerenciamento de Projeto Ágil não é uma teoria
alternativa à teoria de gerenciamento de projetos tradicional específica para
determinado tipo de projeto. É uma maneira de pensar um novo conjunto de
métodos e práticas que somariam ao corpo de conhecimento tradicional de
gerenciamento de projetos. Segundo o autor, a definição que serve como proposta
em seu livro-texto é:
O Gerenciamento Ágil de Projetos é uma abordagem fundamentada em um conjunto de princípios, cujo objetivo é tornar o processo de gerenciamento de projetos mais simples, flexível e iterativo, de forma a obter melhores resultados em desempenho (tempo, custo e qualidades), menor esforço em gerenciamento e maiores níveis de inovação e agregação de valor ao cliente.
Entende-se que a melhor forma de se estudar e implantar o conceito de
gerenciamento ágil de projeto não é recriando todo um corpo teórico alternativo,
deve-se entender a especificidade e trabalhar no sentido de complementação
(AMARAL, CONFORTO, et al., 2011).
Principais diferenças entre as metodologias
Segundo Daniel Amaral et al. (2011, p. 22) analisando os diversos autores
extraem-se quatro diferenciais significativos entre a teoria do Gerenciamento Ágil de
Projeto e a teoria tradicional: autogestão, visão, iteração e envolvimento com o
cliente.
No Gerenciamento Ágil de Projetos há uma necessidade de maior esforço em
criar uma cultura e uma motivação para a autogestão. Os membros das equipes são,
na maioria, especialistas e possuem maiores responsabilidades com o crescimento
das ferramentas computacionais, estão mais expostos as informações de
andamento do projeto devido a seu menor número. Por consequência faz-se
necessário envolver mais os membros da equipe nas atividades gerenciais e utilizar
o potencial desses membros em antecipar os problemas numa atitude mais
45
proativa. Porém se a empresa não possui a cultura e um nível de maturidade
adequado, e os membros da equipe não estiverem preparados para assumir a nova
responsabilidade, ou não estiverem capacitados para tal, se tornará um problema de
caos organizacional (AMARAL, CONFORTO, et al., 2011).
O termo visão é outro diferencial na metodologia de Gerenciamento Ágil de
Projetos, ele deve ser extremamente valorizado pelos gestores que pretendem
aplicar o APM. Assim como o escopo, a visão tem o papel de descrever o contorno,
os resultados que o projeto precisa atingir para satisfação dos stakeholders e quais
as exclusões do projeto. Porém, na abordagem APM a visão deve apresentar
qualidades adicionais se comparadas ao escopo. Ela tem a necessidade de ser
desafiadora e motivadora; tem que ser concisa e antecipar a concepção do produto.
A teoria de escopo enfatiza que é preciso uma concepção concisa do produto,
isto é, mais detalhada. Exige uma exploração de possíveis concepções logo no
início do projeto, exigindo uma habilidade mais técnica e um conhecimento profundo
do produto ou projeto final do gerente de projeto. Isso implica diretamente em uma
definição mais burocrática que a definição de visão, com uma necessidade de maior
detalhamento dos requisitos do projeto gerando um volume maior de documentos
com as especificações de projeto.
A concepção tradicional de gerenciamento diz que o escopo tem origem na
ideia que uma solução será gerada no decorrer do projeto, porém em onde a
exigência de velocidade ou que envolvam grande teor de inovação certamente faz
sentido antecipar essa concepção (AMARAL, CONFORTO, et al., 2011). Portanto a
principal diferença da visão seria uma antecipação de uma solução inicial do projeto.
Ela pode mudar e está aberto para isso conforme estabelecido nos princípios do
Gerenciamento Ágil (AMARAL, CONFORTO, et al., 2011).
Segundo o mesmo autor o princípio de iterações é um dos mais discutidos
pelos autores e um dos principais diferenciais à teoria tradicional. Seria o
planejamento em detalhes apenas em curto prazo e conduzir ciclos curtos de
execução e testes. Esse planejamento seria muito difícil de ser realizado em grandes
empreendimentos, com um grande número de pessoas envolvidas. Essas pessoas
gerariam uma grande quantidade de dúvidas o que impediam a pronta realização
46
das atividades do projeto. Para esse tipo de empreendimento o planejamento e
controle feito do começo ao fim faz sentido e ainda o fará em projeto com menor teor
de inovação e grandes equipes. É o caso em projetos com recursos de comunicação
rápida e tecnologia da informação o recurso de iteração poderá ser explorado, neles
o planejamento poderá ser realizado, detalhado e controlado continuamente ao
longo do projeto.
Nas iterações a ideia é, da visão identificar o produto final e dele algo que pode
ser entregue e realizar ciclos de construção, teste e validação. O foco está nas
entregas de valor do produto, não há em essência o planejamento completo das
atividades, entregas, recursos. Assim não há um o enfoque em planejamentos de
ondas sucessivas citado no PMBOK, onde o projeto é dividido em marcos que
determinam um conjunto de entregas importantes havendo um planejamento
sistemático da fase inteira (AMARAL, CONFORTO, et al., 2011).
Para Daniel Amaral et al. (2011, p. 26) o envolvimento do cliente e a
simplicidade são umas características fundamentais do Gerenciamento Ágil de
Projetos. Mesmo no Gerenciamento de Projetos tradicional há a incorporação das
necessidades dos clientes através dos levantamentos de requisitos, testes,
aprovação de escopo entre outras. Porém na abordagem tradicional há um
detalhamento cada vez maior do plano de projeto com o objetivo de chegar a um
grau de maturidade no qual os recursos, atividades, entregas e prazos sejam
determinados sobrando somente a execução da programação. Para DeCarlo citado
por Daniel Amaral (2011, p. 27) fala que seria impossível fazer tal detalhamento
devido sua complexidade. Para ele um conjunto de instrumentos de medida mais
simples possível, que permita uma negociação e a melhoria continua nas decisões,
por meio de uma comunicação ativa e das contribuições dos membros da equipe
mais proativa seria uma forma de controle de projeto mais sofisticada. Significaria
uma transformação dos propósitos e métodos por outros mais fáceis de usar e que
possibilitem alertas e diminuam a complexidade do problema dividindo em partes e
distribuindo para os diversos membros de equipe.
Segundo o mesmo autor no Gerenciamento Ágil de Projetos há uma proposta
de envolvimento do cliente mais forte até de maneira presencial, estando ele
47
participando das decisões de projeto como um membro ativo da equipe do projeto.
Ele ajudará no desenvolvimento do projeto por meio de técnicas de interação.
48
4. CONCLUSÕES
Não há como classificar uma das duas metodologias como a melhor, o que se
deve fazer é adaptar a metodologia que melhor se encaixa para o projeto que se
está trabalhando. Deve-se fazer uma análise do ambiente interno da empresa,
levando em consideração os aspectos organizacionais e culturais, do contexto
externo em qual o projeto se encontra e assim selecionar o modelo de
gerenciamento que melhor se encaixa para cada tipo de projeto e usar os
processos, técnicas, ferramentas ou práticas adequadas.
Quando os projetos que estão sujeitos à muitas mudanças, os requisitos são
passíveis de alterações, as entregas podem ser curtas, permitem uma melhoria
contínua, possuem uma equipe pequena, há condições para uma comunicação
intensa e participação do cliente ele terá características para um gerenciamento ágil.
Porém somente estas características não garantem o sucesso do projeto. Fatores
como uma mudança cultural, abstenção do gerente de projeto nas decisões em time,
os membros assumirem a responsabilidade por essas decisões, um cliente integrado
ao time, um comprometimento geral do time condições para um planejamento
iterativo, são fundamentais para a implementação de um Gerenciamento Ágil de
Projetos.
Dentre esses fatores, dois parecem fundamentais na bibliografia estudada, a
presença do cliente e o comprometimento da equipe de projeto. O compromisso do
usuário final é fundamental para o sucesso do projeto, seja pela presença no time
como um dos princípios do Gerenciamento Ágil de Projeto, ou pelo gerenciamento
das expectativas dos stakeholders no gerenciamento tradicional. Mas nem sempre é
possível esta presença física do cliente, porém o gerente de projeto deve tentar ao
máximo essa integração. O autor desse trabalho acredita, por exemplo, que em
projetos de engenharia civil onde o produto final seria uma memória de cálculo de
uma estrutura, esta tarefa poderia ser dividida em etapas como: modelagem em
programa estrutural; dimensionamento da estrutura; e produção da memória de
cálculo. Ao terminar a modelagem, antes mesmo do dimensionamento, este modelo
poderia ser enviado para o cliente para sua validação, essa etapa poderia ser
49
facilitada por um programa de modelagem em três dimensões. Assim, mesmo o
cliente não estando presente fisicamente, ele irá participar da elaboração da visão
inicial do projeto, aumentando o seu comprometimento com o mesmo.
O PMBOK valoriza os processos num gerenciamento centralizado na figura do
gerente de projeto, já o Gerenciamento Ágil de Projetos foca na capacidade dos
integrantes da equipe e na partilha do gerenciamento com todos os membros da
equipe. Assim o comprometimento da equipe no planejamento é um fator crítico para
o sucesso do projeto. Nesse trabalho foi citado muito a característica de autogestão
da equipe, assim a empresa e a equipe devem ter um nível de maturidade em
gerenciamento de projeto para implementar o Gerenciamento Ágil de Projetos. O
excesso de formalidades pode engessar a equipe de projetos e limitá-la, porém não
se pode confundir a informalidade de uma equipe autogerida com um ambiente
caótico, desprovido de processos que levam ao objetivo principal do projeto.
A documentação de todos os elementos do projeto pode torna-se desgastante
e desnecessário em projetos de pequeno porte, simples e com equipes pequenas.
Porém em projetos de maior porte e mais complexos a falta de informações e
documentação pode trazer grandes dificuldades no entendimento dos objetivos do
projeto e nas tomadas de decisão, principalmente quando da necessidade ou da
solicitação de mudanças. Assim se deve procurar o melhor das duas metodologias e
aplicá-las de acordo com cada tipo de projeto. Por exemplo, em projetos de grande
porte onde envolvem várias disciplinas o gerenciamento tradicional poderia ser
aplicado de maneira macro no projeto e o Gerenciamento Ágil ser aplicado
internamente nas disciplinas que possuem características para tal. Não se devem
descartar todos os conhecimentos oferecidos pelos métodos tradicionais e sim
combiná-los com as práticas de Gerenciamento Ágil de Projetos.
50
REFERÊNCIAS BIBLIOGRÁFICAS
AMARAL, D. C. et al. Gerenciamento Ágil de Projetos . 1ª. ed. São Paulo: Saraiva,
2011. 240 p.
KERZNER, H. Gestão de Projetos - As melhores práticas . 2ª. ed. Porto Alegre:
Bookman, 2006. 824 p.
PMI. Um guia do Conhecimento em Gerenciamento de Projeto s(Guia PMBOK) .
4ª. ed. Atlanta: PMI Book Service Center, 2008.
SOTILLE, M. A. et al. Gerenciamento do Escopo em Projetos . 2ª. ed. Rio de
Janeiro: FGV, 2010. 172 p.
VALLE, A. B. D. et al. Fundamentos do Gerenciamento de Projetos . 1ª. ed. Rio de
Janeiro: FGV, 2007. 172 p.
XAVIER, C. M. D. S. Gerenciamento de Projetos - Como definir e controla r o
escopo do projeto . 2ª. ed. São Paulo: Saraiva, 2009.
XAVIER, C. M. D. S. et al. Metodologia de Gerenciamento de Projetos -
Methodware . 2ª. ed. Rio de Janeiro: Brasport, 2009.