GESTÃO DA QUALIDADE EM PROJETOS
autoras
HELCIMARA AFFONSO DE SOUZA MARINA SANCHES PAGLIARUSSI
1ª edição SESES rio de janeiro 2016
Conselho editorial regiane burger; roberto paes; gladis linhares; karen bortoloti; helcimara affonso de souza Autoras do original helcimara affonso de souza; marina sanches pagliarussi Projeto editorial roberto paes Coordenação de produção gladis linhares Coordenação de produção EaD karen fernanda bortoloti Projeto gráfico paulo vitor bastos Diagramação bfs media Revisão linguística amanda carla duarte aguiar Imagem de capa robert kneschke | dreamstime.com
Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.
Dados Internacionais de Catalogação na Publicação (cip) S729g Souza, Helcimara
Gestão da qualidade em projetos / Helcimara Souza; Marina Sanches
Pagliarussi
Rio de Janeiro : SESES, 2016.
168 p. : il.
isbn: 978-85-5548-208-3
1. Gestão da qualidade. 2. Gerenciamento de projetos. 3. PMI. 4. PMBOK. I. SESES. II. Estácio.
Diretoria de Ensino — Fábrica de Conhecimento Rua do Bispo, 83, bloco F, Campus João Uchôa Rio Comprido — Rio de Janeiro — rj — cep 20261-063
cdd 658.4013
Sumário Prefácio 7 1. Introdução ao Gerenciamento de Projetos 1.1 Introdução ao Gerenciamento de Projetos 1.2 Definindo Projeto 1.2.1 O que é um projeto bem-sucedido? 1.3 O PMI e sua certificação 1.4 Ciclo de Vida e da Organização de um Projeto 1.4.1 Características do ciclo de vida do projeto 1.4.1.1 Potencial de Adicionar Valor ao Projeto 1.4.1.2 Custo das Mudanças ou Correções 1.4.1.3 Capacidade de Adequação 1.4.1.4 Incerteza do Risco x Quantidade Arriscada 1.5 As Fases do Ciclo de Vida do Projeto 1.6 Principais Áreas de Conhecimento do Projeto segundo PMBOK
2. Gerenciamento de Integração e Gerenciamento de Escopo 2.1 Processo de Integração do Projeto 2.1.1 Desenvolver o termo de abertura do projeto 2.1.2 Desenvolver o plano de gerenciamento do projeto 2.1.3 Orientar e gerenciar a execução do projeto 2.1.4 Monitorar e controlar o trabalho do projeto 2.1.5 Realizar o controle integrado de mudanças 2.1.6 Encerrar o projeto ou fase 2.2 Gerenciamento de Escopo 2.2.1 Coletar os requisitos
9 12 17 21 25 28 30 30 31 31 32 33 38
51 54 56 59 59 60 60 61 61 63
3. Gerenciamento de Tempo, de Custo e Gerenciamento de Recursos Humanos 3.1 Gerenciamento de Tempo 3.2 Processos do Gerenciamento do Tempo 3.3 O Gerenciamento de Custo 3.3.1 Processos de Gerenciamento de Custos 3.3.1.1 Estimar os custos 3.3.1.2 Determinar o orçamento 3.3.1.3 Controlar os Custos 3.3.2 Fatores Importantes 3.3.3 Plano de Gerenciamento de Custos 3.4 O Gerenciamento de Recursos Humanos 3.4.1 O desenvolver o plano de recursos humanos 3.4.2 Mobilizar a equipe do projeto 3.4.3 Desenvolver a equipe do projeto 3.4.4 Gerenciar a equipe do projeto
81 83 86 102 104 104 104 105 105 106 106 108 108 108 109
4. Gerenciamento de Riscos, Comunicações, da Qualidade, do Gerenciamento de Aquisições e Partes Interessadas
113
4.1 Gerenciamento das Comunicações 4.1.1 O Processo de Comunicação 4.1.2 Como Identificar um bom plano de comunicação 4.1.3 Planejamento das Comunicações segundo o PMBOK 4.1.4 Processo de Gerenciamento da Comunicação 4.2 Gerenciamento de Riscos 4.2.1 Planejar o gerenciamento de riscos 4.2.2 Identificar os riscos 4.2.3 Realizar a análise qualitativa de riscos 4.2.4 Realizar a análise quantitativa de riscos 4.2.5 Planejar as respostas a riscos 4.2.6 Monitorar e Controlar os riscos
115 116 117 118 118 121 122 122 122 123 123 123
4.3 Gerenciamento das Aquisições 4.3.1 Planejar as Aquisições 4.3.2 Conduzir as Aquisições 4.3.3 Administrar as Aquisições 4.3.4 Encerrar as Aquisições 4.4 Gerenciamento dos Stakeholders – Partes Interessadas 4.4.1 Identificar as partes Interessadas 4.4.2 Planejar o gerenciamento das partes interessadas 4.4.3 Gerenciar o envolvimento das partes interessadas 4.4.4 Controlar o nível de comprometimento das partes Interessadas
5. A Qualidade Num Projeto e o Processo de Gerenciamento da Qualidade
123 124 125 125 125 126 127 127 128 128
133
5.1 Visões da Qualidade 5.2 Conceitos de Qualidade segundo Deming 5.3 Eras da Qualidade 5.4 A Qualidade num Projeto, segundo PMI 5.4.1 Conceito de Qualidade 5.4.2 Princípios Básicos 5.4.3 Processo de Gerenciamento da Qualidade em Projetos Segundo PMBOK
136 136 140 144 145 145
5.4.4 Planejamento da Qualidade 5.5 Plano de Gerenciamento da Qualidade 5.6 O que usamos para elaborar o plano 5.7 Controle da Qualidade
146 147 148 149
146
Prefácio Prezados(as) alunos(as), Bem-vindo a mais uma disciplina de seu curso! A disciplina de Gestão da Qualidade em Projetos tem como pano de fundo as Boas práticas do PMI, uma certificação que capacita e habilita profissionais da área de gerenciamento de projetos e executar seus projetos com base numa lista de ações tidas como arcabouço para o sucesso na execução de um projeto. Sob um olhar mais amplo, qualquer atividade que executamos em nosso dia a dia, mesmo que uma ida a um supermercado, pode ser tratada como um projeto. A lista de compras é o objetivo do projeto, o tempo disponível para as compras é o prazo, e o custo do projeto é o preço das compras. Se você planejar bem, comprará o que precisa, poupará seu tempo nesta atividade de ida ao supermercado e, comprando somente o que precisa, economizará seu dinheiro. Em outras palavras, sua ida ao supermercado foi um sucesso! O gerenciamento de projetos também passa por essas etapas. Guardadas as proporções de complexidade de cada projeto, as etapas que consiste um processo de gestão de projeto são as mesmas. Gerenciamento de projetos, por essência, existe em diferentes formas e há muito tempo, mesmo quando não se conhecia com este nome. O uso sistemático de planejamento de projetos começou a se firmar em meados deste século. Engenheiros civis resolveram que uma tarefa seria dividida em séries de operações; o esquema de operações seria decidido pelos responsáveis pela execução e, a partir daí, uma sequência ordenada de execução se desenvolverá, resultando em eficiência (VARGAS, 2009). Com a atual onda de competitividade global, o desenvolvimento de um novo produto, a implementação de uma nova tecnologia ou uma mudança organizacional obrigam as organizações a achar uma forma mais ágil e eficaz, de atingir seus objetivos. Essas organizações estão promovendo a ideia de time, que une qualidades interpessoais consideradas fundamentais em um projeto de sucesso. E quando os projetos extrapolam as barreiras da empresa ou mesmo, quando se tornam internacionais, cria-se a necessidade de entender também as barreiras culturais e o contato e a comunicação passa a ter como instrumento as ferramentas de tecnologia da informação, facilitando as interações e promovendo reuniões virtuais, agregando valor ainda maior nas relações e interações entre os profissionais envolvidos.
7
Um programa de gerenciamento de projetos rigoroso pode proporcionar os métodos, os processos e as qualidades necessárias para uma organização se manter ativa e competitiva com as tendências e desafios do setor em que atua. O gerenciamento de projetos, portanto, coincide, em parte, com o gerenciamento geral e com outras aplicações do conhecimento. O time responsável pelo projeto deve entender sua relação com o ambiente de negócios, que envolve meios maiores, como ciclos de vida, empreendedores, influência organizacional, habilidades de gerenciamento e influências socioeconômicas. Muito do conhecimento necessário para gerenciar projetos é exclusivo do gerenciamento de projetos, e as técnicas se diferem das utilizadas para se gerenciar projetos em curso ou operacionais. Um desafio para o gerenciamento de projetos e para o gerente de projetos, portanto, é ajudar a organização a desenvolver uma consciência dos temas globais e os mecanismos para responder efetivamente a eles, assegurar que tecnologias facilitadoras são identificadas e usadas para ir ao encontro das exigências para uma organização global e identificar meios para o desenvolvimento e a disseminação dos produtos e serviços exigidos pelo cliente global (VARGAS, 2009). Bons estudos!
1 Introdução ao Gerenciamento de Projetos
Várias são as razões que levam as organizações a buscar qualidade em suas atividades e no gerenciamento de projetos essa realidade não é diferente. A qualidade hoje é tida como uma das principais razões de sucesso nos projetos organizacionais. São inúmeras as expectativas tanto dos executivos das empresas quanto seus clientes, passando pelos seus colaboradores, fornecedores, sociedade de modo geral, ou seja, todos os stakeholders que fazem parte do negócio, esperam bons resultados e eficácia das empresas. Este cenário por si só já é desafiador. Implantar qualquer ação ou estratégia sem um profundo estudo de seu êxito, já é uma falha na gestão de uma organização. Estamos falando de projeto, que é a fase que antecede a execução de um processo, seja ele estratégico, tático ou operacional. De todos os stakeholders, sabemos que o mais importante para as empresas são sem dúvida, os clientes. Toda organização enfrenta a difícil tarefa de executar projetos que atendam ou superem as expectativas de seus clientes. No entanto, globalmente, inúmeros projetos são mal sucedidos e concluídos fora do orçamento e prazos estabelecidos. Eles não cumprem as normas de qualidade e os requisitos esperados pelo cliente. Uma das causas para o seu fracasso pode ser atribuída a processos desalinhados e ineficientes resultantes de uma combinação de problemas, tais como uma gestão do projeto debilitada, estimativa de custos pobres, mal planejamento e programação, gerenciamento de requisitos inadequado, planejamento de contingência inapropriado, bem como muitos outros. Vamos conhecer os conceitos essenciais desse assunto tão importante para o sucesso organizacional! Stakeholders: São indivíduos e organizações ativamente envolvidos direta ou indire-
tamente num projeto, cujos interesses são afetados (positiva ou negativamente) por ele, ou que exercem influência sobre o mesmo. Incluem o gerente de projeto, o cliente, a organização que fará o projeto, os membros da equipe de projeto, o sponsor/patrocinador (indivíduo/grupo interno ou externo que provê os recursos financeiros para o projeto). Inclui também partes externas, como fundadores, vendedores, fornecedores, agências governamentais, comunidades afetadas pelo projeto e a sociedade em geral.
10 •
capítulo 1
OBJETIVOS Introdução ao Gerenciamento de Projetos • Definição de Projeto & Gerenciamento de Projetos • O PMI e a certificação PMP • Fases e Ciclos de Vida de Projetos de TI • Áreas de conhecimento do Gerenciamento de Projetos
capítulo 1
• 11
1.1 Introdução ao Gerenciamento de Projetos Para iniciar este capítulo, gostaríamos de colocar algumas questões para você refletir. Mas não pense nessas questões de qualquer maneira, mas sim como um gestor de negócios. É com esse olhar que deveremos encarar esta disciplina, como um executivo, administrador de uma corporação. Vamos discutir um pouco as questões acima. Mas é importante lembrar que aqui não há nenhum especialista em artes, esportes ou história japonesa e a nossa discussão será superficial, apenas para introduzir a importância do estudo em gerenciamento de projetos. Você consegue pintar quadros como Leonardo Da Vinci? Provavelmente não, ele era um gênio e dominava a arte da pintura. Porém, com um bom curso de pintura você poderá pintar bons quadros. Não é mesmo? O que estamos tentando dizer é que a ciência pode desenvolver técnicas, procedimentos e processos que servirão de meios (caminhos) para uma produção artística, e, em contrapartida, a arte pode servir de inspiração para o desenvolvimento da ciência. (Borovik; Ramirez; Ramirez, 2010).
COMENTÁRIO Reflita!!! 1. Qual é a diferença entre ciências e artes? 2. Por que o Japão conseguiu se reerguer tão rapidamente da Segunda Guerra Mundial?
Lógico que, somente com as técnicas artísticas desenvolvidas pela ciência, dificilmente iremos criar vários “Leonardo Da Vinci”, pois, como vocês já devem ter estudado, a competência não depende apenas do conhecimento, há, ainda, a atitude e a habilidade cercando este conceito. Contudo, um arcabouço de conhecimentos e técnicas é o começo para a construção dessa competência. Agora vamos refletir nossa segunda pergunta: Por que os japoneses conseguiram se reerguer tão rapidamente após o terror da Segunda Guerra Mundial? Óbvio que são vários os fatores que levaram o Japão a se reerguer tão rapidamente após a Segunda Guerra Mundial, mas gostaríamos de dar atenção a um
12 •
capítulo 1
especial: a implantação nas empresas japonesas, principalmente nas empresas automobilísticas, da técnica da qualidade total. Essa técnica busca atuar principalmente no processo de produção dos bens e serviços para conseguir produtos mais baratos e com maior qualidade, ou seja, busca melhorar a qualidade do processo para, consequentemente, conseguir uma melhora na qualidade do produto. De forma resumida, a técnica de qualidade total é um conjunto de metodologias e ferramentas que devem ser aplicadas ao processo produtivo de forma sistemática, para que este torne-se maduro o suficiente para produzir sempre produtos de qualidade. Portanto, podemos pensar que o sucesso das empresas japonesas no pós-guerra pode ser atribuído à sistematização do processo de produção (principalmente), para que a qualidade do produto pudesse se repetir a cada unidade produzida, independentemente do “heroísmo” das pessoas que estão produzindo cada unidade dessas. Após refletirmos sobre essas duas questões tão distintas e que mostram como o contexto, as técnicas e processos são importantes para o sucesso de uma ideia. Mas você deve estar pensando o que essas reflexões têm a ver com nossa disciplina? E a resposta é simples, porém ela vem também como uma nova pergunta: “como você quer gerenciar os seus projetos?” Fazendo analogia com a discussão que tivemos até aqui, para gerenciar um projeto nós podemos agir pelo lado da arte, dependendo única e exclusivamente da competência e do heroísmo dos gerentes de projetos e torcer, a cada projeto que for realizado, para que tudo dê certo e também torcer para que os gerentes que “saibam” gerenciar um projeto nunca saiam da sua empresa, pois se isto acontecer, juntamente com a saída do seu gerente também irão sair os conhecimentos dele em gerenciamento de projetos. Ou, então, podemos atuar no processo de gerenciamento dos projetos de forma a sistematizá-lo e sempre buscar repetir no projeto presente os sucessos de projetos anteriores, por meio da utilização das melhores práticas, ferramentas e metodologias de gerenciamento de projetos. Na primeira forma, o gerenciamento de projetos pode dar certo para alguns projetos, mas dificilmente os sucessos anteriores serão repetidos em projetos presentes, pois quase sempre não há uma sistematização que indique o motivo pelo qual o projeto anterior deu certo. Já na segunda forma de se gerenciar um projeto, a instituição (ou a equipe, ou a organização...) define um processo sistemático e formalizado por meio do qual todos os gerentes de projeto devem gerenciar os seus projetos.
capítulo 1
• 13
Dessa forma, é possível identificar nos projetos findados o que ocorreu de errado, para que consertos no processo de gestão possam acontecer inibindo, assim, a repetição da falha. E como todos os gerentes utilizam o mesmo processo, todos eles irão usufruir desta melhoria. Além do mais, utilizando a segunda forma, o conhecimento de “como gerenciar” fica também na instituição, tornando-se, assim, um ativo dela e não somente um ativo da cabeça de cada gestor. É óbvio que um gestor competente ainda é essencial para a boa execução desse processo de gerenciamento. Contudo, o treinamento de gestores fica mais facilitado, uma vez que o formalismo do processo de gestão permite a reprodução deste conhecimento. Esta facilidade de treinamento permite às empresas (instituições, organizações...) “produzir” ótimos gestores. Então, pessoal, nesta disciplina iremos estudar o gerenciamento de projetos de acordo com a segunda visão discutida, ou seja, iremos estudar as melhores práticas, metodologias e habilidades de gerenciamento de projetos para nos ajudar a estabelecer procedimentos que nos apoiem no gerenciamento dos projetos das nossas empresas, instituições ou, por que não, de nossas vidas. Mas, por que estudar gerenciamento de projetos? Difícil encontrar projetos que tiveram total êxito, não é mesmo? Eles até existem, mas são difíceis de serem encontrados. Isso porque são muitas as variáveis que fazem com que um projeto tenha tanta complexidade. Para confirmar essa dificuldade em encontrar projetos que terminaram com sucesso, vamos analisar um exemplo simples, da área de tecnologia da informação, de um relatório “Chaos Report”, realizado pelo Standish Group, em 1995, sobre projetos da área de TI e seus resultados. PROJETOS DE TI Terminam no prazo e no orçamento previstos Apresentam reinícios Aumento médio no custo
16,2% 94% 189%
Aumento médio do cronograma
239%
Tabela 1.1 – Projetos de TI segundo o Standish Group. Fonte: www.pmi.org.br/benchmark.
Perceba, na tabela 1.1, que apenas 16,2% dos projetos terminam dentro do orçamento e prazo predeterminados. Na mesma tabela, ainda podemos
14 •
capítulo 1
verificar que, na média, os projetos de TI apresentam um acréscimo de 189% nos custos e de 239% no prazo. O mesmo relatório do Standish Group ainda diz que o custo de oportunidade perdido é algo imensurável, podendo atingir trilhões de dólares. Vocês podem estar pensando: “mas lógico, construir software deve ser algo complexo, de forma que em outras áreas isso não deve acontecer”. Se vocês estão pensando assim, já aviso que este pensamento não traduz a realidade. Veja a tabela 1.2, que mostra os números de um estudo de Benchmark realizado em 2009 pelo PMI (Project Management Institute, que é uma organização que iremos estudar mais à frente) no Brasil, com empresas das mais variadas áreas de atuação. Por meio dos números, é possível perceber que os projetos nas empresas pesquisadas, assim como os projetos de TI vistos acima, em sua maioria, apresentam problemas de prazo e custo. E também é possível perceber que grande parte dos projetos apresentam problemas de qualidade e de satisfação do cliente. PROJETOS EM DIVERSAS ÁREAS – 2009 Projetos que não terminam dentro do custo estabelecido Projetos que não terminam dentro do prazo estabelecido Projetos com problemas de qualidade Projetos com problemas com a satisfação do cliente
62% 79% 41% 34%
Tabela 1.2 – Benchmarck realizado pelo PMI em 2009 (PMI, 2009).
Conseguiram perceber, por meio dos números mostrados acima, como é complexo um projeto, ou seja, como o histórico dos projetos está repleto de insucessos e com projetos estourando custos, prazos e sendo finalizado com a geração de um produto/serviço que está muito aquém da qualidade esperada? Neste momento, é bem possível que vocês estejam se perguntando: O que é que faz com que os projetos falhem? A mesma pesquisa de Benchmarck feita em 2009 pelo PMI também pesquisou quais foram os problemas que ocorreram com mais frequência nos projetos das organizações pesquisadas. A tabela 1.3 a seguir, mostra os 10 principais problemas.
capítulo 1
• 15
OS 10 PRINCIPAIS PROBLEMAS ENCONTRADOS NOS PROJETOS 1. Problemas de comunicação 2. Não cumprimento dos prazos 3. Mudanças de escopo constantes 4. Escopo não definido adequadamente 5. Concorrência entre o dia a dia e o projeto na utilização de recursos 6. Estimativas incorretas e sem fundamentos 7. Riscos não avaliados corretamente 8. Não cumprimento do orçamento 9. Problemas com fornecedores 10. Retrabalho em função da falta de qualidade do produto
76% 71% 70% 61% 52% 52% 50% 50% 37% 28%
Tabela 1.3 – Benchmarck PMI 2009 – problemas que ocorrem com mais frequência nos projetos da organização. Fonte: www.pmi.org.br/benchmark.
Perceba, no resultado da pesquisa, que os problemas encontrados pertencem às mais diversas áreas do projeto, ou seja, são problemas de prazos e custos mal estipulados, riscos mal avaliados, problema na qualidade do produto final e no escopo do projeto. Bom, até agora mostramos toda a complexidade envolvida no desenvolvimento de projetos por meio de pesquisas feitas em empresas brasileiras e empresas do setor de TI no mundo todo. Vimos também os maiores problemas encontrados nos projetos desenvolvidos nas empresas brasileiras e vimos que esses problemas estão localizados nas mais diversas áreas. Então, nos resta mais uma pergunta: Há alguma técnica científica e sistematizada que garanta que os esforços empreendidos em um projeto levem à entrega de um produto/serviço de qualidade e que atenda, ou exceda, às expectativas do solicitante? Na verdade não existe uma “receita de bolo” única e mágica de como se administrar esses esforços de forma a se ter 100% de sucesso na implementação de um projeto. Então quer dizer que não há ciência por trás da gerência desse esforço de implantação ou desenvolvimento do software, ou a construção de um estádio de futebol ou mesmo de um foguete espacial? Bom, não é bem assim. O que temos na área são coleções/compilações que apresentam práticas, conhecimentos e técnicas historicamente bem-sucedidas quando aplicadas à gerência desses esforços e que, na maioria das vezes, quando bem aplicadas, levam esse conjunto de esforços a entrega bem-sucedida de um produto/serviço.
16 •
capítulo 1
A aplicação deste conjunto de técnicas é o que podemos chamar de gerenciamento de projetos e é por isso que é considerada um tema importante na atualidade: para aprender algumas dessas técnicas em busca do melhor gerenciamento de projetos. Você com certeza precisará desse aprendizado um dia! Portanto, estudando o gerenciamento de projetos você irá aprender técnicas, procedimentos e habilidades que lhe permitirão gerenciar toda essa complexidade de forma sistemática e repetível a ponto de aumentar as chances de implementar um projeto com sucesso e repetir este sucesso em outros projetos futuros. Para fecharmos este tópico, gostaríamos que você fixasse que um projeto é algo complexo e que no mundo há vários exemplos de projetos que não tiveram um final feliz. Contudo, há também projetos que foram finalizados com sucesso, entregando produtos/serviços com qualidade, no tempo e no prazo corretos.
1.2 Definindo Projeto Projetos, dentro de uma empresa, são utilizados como instrumentos para efetuar mudanças ou produzir produtos e/ou serviços. Normalmente, em organizações modernas, projetos surgem como resultado do planejamento estratégico. Resumindo: a organização declara a sua missão (objetivos atuais) e a sua visão (objetivos a médio e longo prazos), então uma análise do ambiente externo e interno é feita identificando ameaças e oportunidades, pontos fortes e fracos; em seguida, levando em consideração a missão, visão e análise externa e interna realizada, a organização formula metas e objetivos estratégicos que serão implementados por meio de vários projetos na organização. Alinhado à ideia do planejamento estratégico, o PMBOK (2008) diz que um projeto pode surgir por meio de (mas não se limita a): • Desenvolvimento de um novo produto ou serviço; • Mudanças organizacionais: estruturais, RH ou estilo; • Aquisição ou implementação de sistemas de informações novos ou então a modificação de sistemas de informações existentes; • Construção de imobilizados; • Implementação de procedimentos e processos de negócios.
capítulo 1
• 17
CONCEITO Um projeto é normalmente definido como um empreendimento colaborativo, frequentemente envolvendo pesquisa ou desenho, que é cuidadosamente planejado para alcançar um objetivo particular. Projetos podem ainda ser definidos como sistemas sociais tempo E uma demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecnológico ou requisito legal. A palavra projeto vem da palavra latina projectum do verbo em latim proicere, "antes de uma ação", que por sua vez vem de pró-, que denota precedência, algo que vem antes de qualquer outra coisa no tempo (em paralelo com o grego pró) e iacere, "fazer". Portanto, a palavra "projeto", na verdade, significava originalmente "antes de uma ação". Quando o idioma Português inicialmente adotou a palavra, ela se referia a um plano de alguma coisa, não o ato de realmente levar esse plano a concretização. Algo realizado de acordo com um projeto tornou-se conhecido como um "objetivo". As principais características dos projetos são: • temporários, possuem um início e um fim definidos. • planejados, executado e controlado. • entregam produtos, serviços ou resultados exclusivos. • desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva. • realizados por pessoas. • com recursos limitados. Fonte: www.pmi.org.br
Mas, afinal de contas, o que é um projeto? Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo! Um projeto é um empreendimento único, com início e fim determinados, que utiliza recursos e é conduzido por pessoas, visando a atingir objetivos predefinidos, caracterizando-se por ser temporário, exclusivo e progressivo. (CAVALIERI, 2005). De acordo com as definições acima, um projeto é algo que tem início e fim, produz um produto ou serviço exclusivo e pode ser feito progressivamente. Vamos entender cada um desses pontos:
18 •
capítulo 1
• Temporário1 : quer dizer que o projeto tem um tempo no qual ele existe, iniciando-se em um determinado momento e tendo um fim determinado. Temporário não quer dizer de curta duração (há projetos que duram décadas), e sim que se trata de um esforço finito. Temporário também não se aplica ao produto/serviço gerado pelo projeto em questão, e sim aos esforços necessários para a geração desses produtos e serviços. Temporário também pode ser relativo à janela de tempo na qual é possível a implementação do projeto. Por último, temporário também se aplica à equipe do projeto. Quando o projeto termina, a equipe é liberada daquele projeto. • Produtos, serviços e resultados exclusivos2 : um produto/serviço gerado por um projeto é diferente de um produto gerado por uma linha de montagem em série. Os projetos geram produtos/serviços exclusivos e, por isso, diferentes de outros produtos e serviços já gerados anteriormente. Em uma organização, é importante diferenciar projetos do trabalho operacional do dia a dia. Enquanto o primeiro trata de esforços correlacionados e temporários para produzir algo único e exclusivo, o segundo trata da realização de processos contínuos e repetitivos.
ATENÇÃO Diferenciando: Projetos, Subprojetos, Programas e Portfólio • Subprojetos: Diversas vezes um projeto precisa ser subdividido em partes, de fácil gerenciamento e controle, essas diversas partes são as denominadas subprojetos. Os mesmos são braços de um mesmo projeto e nunca deve ser tratado isolado desse. • Programa: Esse é um termo usado para identificar um grupo de projetos relacionados que são gerenciados e coordenados de modo integrado, obtendo os benefícios e controles que não existem ao gerenciá-los individualmente. • Portfólio: É um conjunto de projetos, programas e outros esforços que são agrupados para facilitar o atingimento dos objetivos estratégicos do negócio. 1 Um belo exemplo da importância do fator “tempo” em um projeto: imaginem um projeto para desenvolver uma luneta específica para a visualização do cometa Halley: esse projeto só tem sentido se acontecer antes da passagem desse cometa pelo planeta Terra. Posterior a isso, perde-se a janela de oportunidade do projeto. 2 Tomem como exemplo dois prédios idênticos em seu design arquitetônico. Eles são produtos exclusivos ou não? A resposta é sim, eles são exclusivos, pois apesar de serem iguais em seu design, eles podem ter sido construídos em lugares diferentes, exigindo cálculos estruturais diferentes, o que poderia resultar em entregas diferentes, principalmente ligadas à estrutura e à fundação. Ou, então, em épocas diferentes, contando, assim, com fornecedores diferentes e com um ambiente macro e microeconômico diferente, também culminado em entregas diferentes. Ou seja, com resultados exclusivos.
capítulo 1
• 19
Todos esses objetos (Projetos, Programas e Outros esforços) são mensuráveis, ordenáveis e priorizáveis.
Como dito anteriormente, os projetos dentro de uma organização têm por objetivo (e não somente isso) atender ao planejamento estratégico da empresa, sendo temporário e tratado por uma abordagem de gerenciamento de projetos. Já um processo, ou então trabalho operacional do dia a dia, também muito importante para uma organização, são esforços repetitivos e “permanentes” necessários para manter o dia a dia operacional da organização. Esses processos devem ser tratados por uma metodologia de gerenciamento de processos como um PDCA3 (SOUSA, 2006). Muito embora não haja uma “receita de bolo” que leve o projeto ao triunfo, o que temos são grandes compilações de boas práticas de gerenciamento de projeto que, quando aplicadas, aumentarão a chance de sucesso dos projetos.
CONCEITO O Gerenciamento de Projetos é um conjunto de ferramentas gerenciais que permitem que a empresa desenvolva um conjunto de habilidades, incluindo conhecimento e capacidades individuais, destinados ao controle de eventos não repetitivos, únicos e complexos, dentro de um cenário de tempo, custo e qualidade predeterminados.
Há várias compilações existentes, mas há uma que vem se tornando quase que um padrão no mundo. Esta compilação é o PMBOK, desenvolvido pelo PMI. Os benefícios do gerenciamento de projetos são: • O gerenciamento de projetos proporciona inúmeras vantagens sobre as demais formas de gerenciamento, tendo se mostrado eficaz em conseguir os resultados desejados dentro do prazo e orçamento. • A principal vantagem do Gerenciamento de Projetos é que ele não é restrito a projetos gigantescos, ele pode ser aplicado em empreendimentos de qualquer complexidade, orçamento e tamanho. 3 PDCA: ciclo PDCA, ou Shewhart, ou Deming – É um ciclo de desenvolvimento que tem como foco a melhoria contínua de processos. Foi introduzido primeiramente no Japão, após a Segunda Guerra Mundial, e tem as seguintes fases: planejamento (plan), execução (do), controle (control) e ação (act). (WIKEPEDIA, 2010).
20 •
capítulo 1
Dentre os principais benefícios, podemos destacar: • Evita surpresas durante a execução dos trabalhos; • Permite desenvolver diferenciais competitivos e novas técnicas • Antecipa as situações desfavoráveis e permite ações preventivas e corretivas. • Adapta os trabalhos ao mercado consumidor e ao cliente; • Disponibiliza os orçamentos antes do início dos gastos; • Agiliza a tomada de decisão já que as informações estão estruturadas e disponibilizadas. • Aumenta o controle gerencial de todas as fases a serem implementadas. • Facilita e orienta as revisões de estrutura do projeto que forem decorrentes de alterações do mercado, melhorando a capacidade de adaptação do projeto. • Otimiza a alocação de recursos. • Documenta e facilita as estimativas para futuros projetos.
1.2.1 O que é um projeto bem-sucedido? Apesar de a resposta à questão parecer quase que intuitiva, pode ser que formalmente ela não seja tão simples. Para provar o acima dito, desafiamos você a enumerar 3 grandes projetos brasileiros que obtiveram sucesso e 3 grandes projetos brasileiros que foram fracassados. Agora, você deve estar pensando em projetos que foram concluídos e dando a eles o conceito de projetos bem-sucedidos, como, por exemplo, os Jogos Panamericanos do Rio de Janeiro ou, então, o desfile de carnaval de São Paulo de 2010. Ou, então, você deve estar pensando em alguns projetos que não terminaram com a entrega do produto/serviço esperado e dando a eles o conceito de projetos malsucedidos. Mas será que é só isso mesmo? Ou seja, se o projeto entregou o produto esperado, então ele e bem-sucedido e, se o projeto não entregou o produto/serviço esperado, ele é malsucedido?
capítulo 1
• 21
Segundo Vargas (2005) não é assim que se mede o sucesso de um projeto. Na verdade, ainda segundo Vargas (2005), as pessoas tendem a fazer algumas perguntas para verificar se o projeto foi bem-sucedido, como, por exemplo: • O projeto ficou abaixo do orçamento previsto? • O projeto terminou mais rápido do que o previsto? • O projeto consumiu menos materiais ou pessoas do que o previsto? • O cliente foi surpreendido pela qualidade do resultado do projeto? Apesar de o senso comum pensar que respostas positivas às perguntas acima, quando feitas a um determinado projeto, levam a crer que este projeto obteve sucesso, não é bem assim que as boas práticas de gerenciamento de projetos dizem. Na verdade, um projeto termina com sucesso quanto ele é realizado dentro do previamente planejado, Ou seja, no popular: “não pode nem faltar e nem sobrar” daquilo que foi planejado. Ou seja, o que queremos que você entenda é que um projeto bem- -sucedido precisa ser bem planejado e executado dentro desse plano. E ter um projeto que foi executado de forma a não utilizar todo o recurso planejado ou ter um produto/serviço final muito superior ao planejado quer dizer um projeto sem sucesso. Parece difícil de acreditar neste conceito, mas Vargas (2005) nos traz um exemplo bastante interessante: imagine um projeto que tenha por objetivo o lançamento de uma campanha publicitária que renda a venda de 10.000 produtos em uma semana. Após a execução do projeto, conseguiu-se a demanda por 100.000 produtos na semana. O projeto acima descrito foi um projeto bem-sucedido? Vamos analisar um pouco mais a fundo a situação: imaginem que a empresa tenha uma capacidade de produzir 15.000 produtos semanais. A demanda, agora por 100.000, passa a ser um grande problema para a empresa, não é verdade? Por isso, podemos dizer que este projeto não foi bem-sucedido. Para deixar mais claro ainda este conceito, vamos a outro exemplo. Imagine uma empresa de tecnologia da informação que tem um projeto para o qual foram previstos US$1.000.000 para a sua execução. Ao finalizar o projeto, o gerente de projetos diz que sobraram US$700.000. Isso é bom?
22 •
capítulo 1
Na verdade, sobrar dinheiro é bom, mas não quer dizer que o projeto foi bem-sucedido. A sobra de dinheiro no projeto nos leva a crer que este projeto foi mal planejado. Perceba como a situação deste projeto piora se você imaginar que no momento da aprovação deste projeto a diretoria da empresa tenha deixado de executar um outro projeto importante por falta de recursos, e pelo motivo deste segundo projeto não ter sido executado a empresa tenha perdido 50% de sua participação no mercado. Viu só como o projeto em questão não pode ser considerado bem-sucedido? Por causa dele a empresa poderia ter falido e fechado suas portas. Para ajudar você a identificar se um projeto foi bem sucedido, Vargas (2005) sugere as seguintes questões: • O projeto deve ter sido concluído dentro do prazo previsto; • O projeto deve ter sido concluído dentro do orçamento previsto; • O projeto deve ter utilizado os recursos, materiais e humanos, com eficiência e sem desperdícios; • O projeto deve ter sido concluído atingindo a qualidade e o desempenho desejados; • O projeto deve ter sido concluído com o menor número possível de alteração em seu escopo; • O projeto deve ter sido aceito sem restrições pelo contratante ou cliente; • O projeto deve ter sido executado sem interrupções ou prejuízos às atividades normais da instituição; • O projeto não pode ter agredido a cultura da organização.
COMENTÁRIO Causas que levam o projeto ao fracasso Em um de seus podcasts, Ricardo Vargas diz que para levar um projeto ao fracasso basta não gerenciá-lo. Ou seja, de uma maneira bastante irônica, o normal de todo o projeto seria o fracasso. Porém, para o projeto não fracassar, há o gerente de projetos tomando todas as ações necessárias. Mas às vezes, mesmo com todas as ações feitas, os projetos podem falhar ou, então, não atingir o resultado esperado. Vargas (2005) diz que projetos podem falhar por motivos que fogem do controle da organização (riscos do projeto) como, por exemplo:
capítulo 1
• 23
• Mudança na estrutura organizacional da empresa; • Riscos elevados no meio ambiente; • Mudanças tecnológicas; • Evolução dos preços e prazos; • Cenários político-econômicos desfavoráveis. Mesmo esses fatores poderiam ser evitados por meio de uma gerência de riscos eficiente e eficaz. Contudo, estes não são os principais pontos de atenção, uma vez que não são esses os motivos mais frequentes que levam um projeto ao fracasso. Na verdade, os motivos mais frequentes que levam os projetos ao fracasso estão ligados a falhas gerenciais. Vargas (2005) enumera alguma delas, a saber: • As metas e os objetivos do projeto mal estabelecidos ou mal compreendidos. • Subestimação da complexidade do projeto. • Previsão de prazos e custos não realistas. • Planejamento baseado em informações históricas não confiáveis. • Projeto sem líder/gerente responsável ou com vários líderes/gerentes responsáveis, gerando falta de liderança no projeto. • Pouco tempo destinado ao planejamento do projeto. • Expectativas do cliente referente à entrega do projeto foram mal-entendidas. • Planejamento de recursos humanos e materiais mal-feito. • Falta de experiência/conhecimento das pessoas envolvidas na execução do projeto. Acima, enumeramos algumas das falhas gerenciais citadas por Vargas (2005) que levam os projetos ao insucesso. Mas é bom lembrar que não são apenas estas acima citadas as falhas gerenciais que levam os projetos ao insucesso. Por isso, é sempre bom lembrar que o gerente de projetos deve definir e seguir uma metodologia de gerenciamento de projetos que busque minimizar as chances desse tipo de falha ocorrer.
Por isso, nesta disciplina, iremos aprender as melhores práticas de gestão de projetos apresentadas no PMBOK e como aplicá-las. Para tanto, iremos aprender um pouco mais sobre o PMBOK e o PMI e vamos começar a introduzir conceitos importantes para entender o que é um projeto, o que é a gerência de projeto e o que é o gerente de projetos.
24 •
capítulo 1
1.3 O PMI e sua certificação PMI – Project Management Institute (Instituto de Gerenciamento de Projetos) – Fazendo o gerenciamento de projetos indispensável para os resultados dos negócios. O PMI é uma organização sem fins lucrativos, dedicada ao avanço do estado da arte em gerenciamento de projetos, mantendo como compromisso promover o profissionalismo e a ética em gerenciamento de projetos. Foi inicialmente criado na Pensilvânia (EUA), em 1969, por 5 voluntários e hoje conta com uma comunidade de 265.000 associados e 140.000 certificados, sendo considerada a maior e mais acreditada instituição de educação e desenvolvimento de padrões em gerência de projetos. Tente lembrar o que acontecia em 1969 no mundo e contextualize historicamente a criação do PMI e a sua importância para a época. Para atingir esse número de pessoas, o PMI se internacionalizou e hoje está presente em vários países por meio de seus capítulos (ou, em inglês: chapters), que são filiais espalhadas geograficamente, e contribuem nas missões e objetivos do PMI, promovendo o profissionalismo em gerência de projetos, sendo que hoje o PMI está presente em mais de 170 países.
CURIOSIDADE O PMI - Project Management Institute, juntamente com a Economist Intelligence Unit, realizou uma pesquisa sobre o universo dos projetos e constatou que cerca de 12 trilhões de dólares são hoje empregados em projetos. Isso significa aproximadamente 25% de toda a economia mundial, empregando mais de 20 milhões de profissionais em atividades relacionadas à liderança e ao gerenciamento de projetos. Isso confirma o que Tom Peters apresentou em seu artigo “Você é o seu Projeto” em 1999. Ele afirmou que, nos próximos 20 anos, todo o trabalho será desenvolvido por meio de projetos. Pouco mais de 10 anos depois essa realidade é evidentemente comprovada. David Cleland também afirma que, no futuro, o gerenciamento de projetos será utilizado para gerenciar as mudanças em todas as infraestruturas sociais em todos os países, desenvolvidos ou não (VARGAS, 2009), conforme figura a seguir.
capítulo 1
• 25
302.364
2009
2005
70.035
2000
1995
1990
5.272
1985
1980
1.000
1975
1970
17.069
208.660
350.000 325.000 300.000 275.000 250.000 225.000 200.000 175.000 150.000 125.000 100.000 75.000 50.000 25.000
Figura 1.1 – Evolução Mundial dos membros do PMI no mundo. Fonte: Vargas (2009)
O PMI® também oferta aos seus associados, e à população em geral, vários produtos e serviços, entre eles: • Padrões profissionais: O PMI® desenvolve padrões para a prática profissional de gerência de projetos, sendo que um dos principais documentos produzidos é o PMBOK® Guide ou “A Guide to the Project Manager Base of Knowledge” (Um guia para a base de conhecimentos de gerência de projetos). Hoje, o PMBOK® se encontra em sua quarta edição e é aprovado como um padrão nacional (ANS) pelo Instituto de Padrões Nacional Americano (ANSI); • Certificação: O PMI® também oferece programas de certificação profissional para promover o crescimento da profissão de gerenciamento de projetos, sendo que o mais conhecido deles é a PMP ou “Project Manager Professional”. Das principais iniciativas do PMI na difusão do conhecimento em gerenciamento de projetos, sendo as certificações a mais procurada e difundida mundo afora, é a publicação de padrões globais de gerenciamento de projetos, programas e portfólio, sendo a mais popular delas o Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK® - Project Management Body of Knowledge). O PMBOK Guide.
26 •
capítulo 1
• PMBOK O PMBOK® Guide foi o primeiro padrão de práticas profissionais desenvolvido pelo PMI e abrange todo o conhecimento da profissão de gerenciamento de projetos. Ele foi desenvolvido com a ajuda de praticantes e acadêmicos que utilizam de fato essas práticas ou que as desenvolve. Ou seja, o que é apresentado pelo PMBOK® Guide é amplamente testado pelos praticantes de gerência de projetos e aprovado por eles, sendo consideradas boas práticas para a gerência de projetos em muitos projetos na maior parte do tempo, sendo que existe um consenso por parte dos praticantes sobre seus valores e aplicabilidade.
COMENTÁRIO Seu histórico: Em 1983, na tentativa de documentar e padronizar as práticas que são normalmente aceitas na gerência de projetos, foi publicado o artigo "Ethics, Standards, and Accreditation Committee Final Report". A primeira edição do "A Guide to the Project Management Body of Knowledge (PMBOK Guide)" foi publicada pelo Project Management Institute (PMI) foi publicada em 1996, seguida pela segunda edição em 2000. Em 2004, o Guia PMBOK — Terceira Edição — foi publicado com maiores mudanças, considerando as edições anteriores. A quarta edição (lançada em 2008) é normatizada pelas normas ANSI/PMI 99-001-2008 e IEEE 1490-2011. A última versão do Guia PMBOK é a quinta edição que foi publicada em 2013 em Inglês. Traduções estão disponíveis em Árabe, Chinês, Francês, Alemão, Italiano, Japonês, Coreano, Português, Russo e Espanhol. (VARGAS, 2009)
O PMBOK® Guide, além de trazer esse conjunto de boas práticas, também busca estabelecer uma linguagem comum para o profissional de gerenciamento de projeto. (PMBOK, 2008). O PMI® diz que o PMBOK® Guide não deve ser considerado como um documento que contempla a totalidade de conhecimento de gerenciamento de projetos, uma vez que essa profissão é muito dinâmica e sofre atualizações a todo o momento. O guia é baseado em processos e sub-processos para descrever de forma organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha à empregada por outras normas como a ISO 9000 e o Software Engineering Institute's, CMMI.
capítulo 1
• 27
Os processos descritos se relacionam e interagem durante a condução do trabalho. A descrição de cada um deles é feita em termos de: • Entradas (documentos, planos, desenhos etc.); • Ferramentas e técnicas (que se aplicam às entradas); • Saídas (documentos, produtos etc.)
1.4 Ciclo de Vida e da Organização de um Projeto Todo projeto pode ser subdividido em determinadas fases4 de desenvolvimento. O entendimento dessas fases permite ao time do projeto um melhor controle do total de recursos gastos para atingir as metas estabelecidas. Esse conjunto de fases é conhecido como ciclo de vida. O ciclo de vida possibilita que seja avaliada uma série de similaridades que podem ser encontradas em todos os projetos, independentemente de seu contexto, aplicabilidade ou área de atuação. O ciclo de vida pode ser dividido em um conjunto de fases, normalmente fixas para todos os tipos de projeto, contendo uma séria de passos principais do processo de contextualizar, desenhar, desenvolver e colocar em operação uma determinada necessidade do projeto. Essas fases, por sua vez, são subdivididas em estágios, ou etapas específicas, de cada natureza de projeto (construção, desenvolvimento de produtos, etc.). Esses estágios são, então, subdivididos em atividades, ou tarefas específicas de cada projeto.
FASES
Genérico para todos os projetos
MACROVISÃO ESTÁGIOS
Específicos da natureza do projeto
MICROVISÃO ATIVIDADES
Específicos de cada projeto
Figura 1.2 – Visão do ciclo de vida do projeto. Fonte: Vargas (2009). 4 Em muitos casos existem diferentes interpretações do conceito de fase e de grupo de processos. Neste contexto, segundo Vargas (2009), o conceito de “fase” será utilizado para significar tanto os grupos de processo do PMBOK Guide quanto os conceitos e fases específicas de um projeto (por exemplo: design, construção, testes). Portanto, o termo “grupo de Processos de Iniciação” e “Fase de Iniciação” são considerados sinônimos neste material.
28 •
capítulo 1
Conhecer as fases do ciclo de vida proporciona uma séria de benefícios para quaisquer tipos de projetos. Dentre eles, podem ser destacados os seguintes: • correta análise do ciclo de vida determina o que foi, ou não, feito pelo projeto; • o ciclo de vida avalia como o projeto está progredindo até o momento; • o ciclo de vida permite que seja indicado que o ponto exato em que o projeto se encontra no momento. Ao longo do ciclo de vida, diversas considerações podem ser feitas, principalmente: • as características do projeto tendem a mudar com a conclusão de cada fase do projeto; • incerteza relativa aos prazos e custos tende a diminuir com o término de cada fase. A descrição do ciclo de vida do projeto pode ser genérica, representada por um único gráfico, ou detalhada incluindo vários gráficos, fluxogramas e tabelas, específicos de cada atividade. Com relação à velocidade de desenvolvimento, o ciclo de vida dos projetos pode ser caracterizado, na maioria das vezes, por um início lento seguido de um progresso acelerado até atingir um pico e logo em seguida, um desaceleramento até atingir seu término. 100
% COMPLETO
Final lento
Momento de velocidade
Início lento 0 TEMPO
Figura 1.3 – Ciclo de vida do projeto segundo critérios de velocidade de desenvolvimento. Fonte: Vargas (2009).
capítulo 1
• 29
Outra consideração a ser analisada no ciclo de vida do projeto é o nível de esforço. O nível de esforço destinado ao projeto inicia-se em praticamente zero e vai crescendo até atingir um máximo e, logo após esse ponto, reduz-se bruscamente até atingir o valor zero, representante do término do projeto. Entende-se, segundo Vargas (2009), por esforço, a quantidade de pessoas envolvidas no projeto, o dispêndio de trabalho e dinheiro com o projeto, as preocupações, as complicações, as horas-extras, etc. A localização do valor máximo do gráfico pode variar de projeto para projeto. A suavidade desse ponto de esforço máximo está diretamente relacionada à qualidade com que o planejamento foi realizado. Quanto melhor é o plano, mais suave é a transposição do ponto de esforço máximo.
ESFORÇO
Máximo
Início
TEMPO
Término
Figura 1.4 – Variação do esforço com o tempo para o projeto. Fonte: Vargas (2009).
1.4.1 Características do ciclo de vida do projeto A maioria dos ciclos de vida dos projetos compartilham algumas características comuns, representadas a seguir (VARGAS, 2009). 1.4.1.1 Potencial de Adicionar Valor ao Projeto O potencial de adicionar valor a um projeto, segundo Vargas (2009), é, obviamente, alto no início do projeto, quando a maioria das definições ainda está no papel, caindo até o término do projeto, quando o potencial de adicionar valor ao projeto tende a ser mínimo.
30 •
capítulo 1
Potencial de adicionar valor Baixo
Início
Tempo
Término
Figura 1.5 – Potencial de adicionar valor ao projeto em função do desenrolar do projeto. Fonte: Vargas (2009).
1.4.1.2 Custo das Mudanças ou Correções
Custo das mudanças / correções
O custo de promover mudanças no projeto é pequeno nas fases iniciais, crescendo exponencialmente com o progresso do projeto até chegar ao seu custo total, podendo até mesmo superá-lo.
Início
Tempo
Término
Figura 1.6 – Custo das mudanças / correções em função do desenrolar do projeto. Fonte: Vargas (2009).
1.4.1.3 Capacidade de Adequação A capacidade de adequação do projeto quanto a novas necessidades, ou seja, a capacidade de se alterarem as características finais do projeto é grande no
capítulo 1
• 31
início, caindo gradativamente com o passar do tempo. Quanto mais o projeto se desenvolve, menor é a capacidade de adequação.
Capacidade de adequação
Alta
Baixa Início
Tempo
Término
Figura 1.7 – Capacidade de adequação do projeto a novas necessidades no seu desenrolar. Fonte: Vargas (2009).
1.4.1.4 Incerteza do Risco x Quantidade Arriscada No início do projeto a incerteza do Risco do projeto em questão é bastante elevada, pois não se tem total visão do que poderá acontecer com o mesmo, entretanto a quantidade arriscada é muito pouco pois o projeto ainda está no início. Ao se comparar a incerteza do risco com a quantidade arriscada, tem-se que, no início do projeto, o nível de incerteza é elevado, porém a quantidade arriscada é pequena, uma vez que se está em uma fase inicial do projeto (VARGAS, 2009). Com seu desenrolar, a incerteza a respeito do risco diminui enquanto a quantidade arriscada aumenta, já que o projeto se encontra em fase avançada de execução. O período mais crítico é o período de transição, quando se tem o mais alto impacto do risco (maior produto probabilidade x quantidade arriscada), considerando que o impacto do risco pode ser dado como o produto da incerteza do risco pela quantidade arriscada. Essa região coincide exatamente com o ponto máximo de esforço na relação esforço x tempo, descrita anteriormente, indicando que o pico de esforço está exatamente, na região de maior impacto dos riscos (VARGAS, 2009).
32 •
capítulo 1
Incerte
risco
Intensidade
Região de maior impacto do risco
za do
iscada
ade arr
Quantid
Início
Tempo
Término
Figura 1.8 – Análise comparativa da incerteza dos riscos com a quantidade arriscada. Fonte: Vargas (2009).
1.5 As Fases do Ciclo de Vida do Projeto As fases do ciclo de vida do projeto dependem, intimamente, da natureza do projeto. Um projeto é desenvolvido a partir de uma ideia, progredindo para um plano, que, por sua vez é executado e concluído. Cada fase do projeto, segundo Vargas (2009), é caracterizada pela entrega, ou finalização, de um determinado trabalho. Toda entrega deve ser tangível e de fácil identificação, como, por exemplo, um relatório confeccionado, um cronograma estabelecido, um conjunto de atividades realizado. O Guia PMBOK em sua 5° Edição provê diretrizes para gerência dos projetos individualmente e define conceitos associados à gerência de projetos. Isto também descreve o ciclo de vida do gerenciamento do projeto e seus processos relacionados, assim como o ciclo de vida do projeto. O Guia PMBOK reconhece 47 processos que recaem em 5 grupos de processos e 10 áreas de conhecimento que são típicas em quase todas áreas de projetos. Genericamente, o ciclo de vida de um projeto pode ser dividido em fases características, conforme a figura a seguir.
capítulo 1
• 33
Fase de encerramento
Fase de execução
Fase de planejamento
Fase de iniciação
Esforço
Fase de monitoramento e controle
Tempo
Figura 1.9 – Figura: O ciclo de vida do projeto subdividido em fases. Fonte: Vargas (2009).
Cada fase ou grupo do projeto normalmente define: • qual é o trabalho técnico que deve ser realizado; • quem deve estar envolvido. O número de fases em um projeto é função de sua natureza, podendo variar entre quatro e nove fases características. Porém para efeitos didáticos, serão consideradas apenas cinco fazes características, as quais também são denominadas grupos de processos pelo PMBOK.. • Fase de Iniciação: É a fase inicial do projeto, quando uma determinada necessidade é identificada e transformada em um problema a ser resolvido. A missão e o Objetivo do projeto são definidos , os documentos iniciais confeccionados e as melhores estratégias selecionadas. • Fase de Planejamento: É a fase responsável por detalhar tudo aquilo que será realizado pelo projeto, incluindo cronograma, interdependência entre atividades, alocação de recursos, analise de custos. Nessa fase, os planos de escopo, custo, qualidade, recursos humanos, comunicação, risco e aquisição são desenvolvidos. • Fase de Execução: É a fase que materializa tudo aquilo que foi planejado anteriormente. Grande parte do orçamento do esforço do projeto é consumido nessa fase. • Fase de Monitoramento e Controle: É a fase que acontece paralelamente às demais fases do projeto. Tem como objetivo acompanhar e controlar aquilo que está sendo realizado pelo projeto. O objetivo do controle é comparar o status atual do projeto com o status previsto pelo planejamento.
34 •
capítulo 1
• Fase de Encerramento: É a fase quando a execução dos trabalhos é avaliada através de uma auditoria interna ou externa, os documentos do projeto são encerrados e todas as falhas ocorridas durante o projeto são discutidas e analisadas para eu erros similares não ocorram em novos projetos. Esta fase portanto, também é conhecida como fase de aprendizado.
Intensidade
Planejamento
Execução
Iniciação Encerramento Controle
Tempo CONCEITO DESENVOLVIMENTO IMPLEMENTAÇÃO TREINAMENTO FAZES DO CICLO DE VIDA DO PROJETO Figura 1.10 – Fases do ciclo de vida do projeto. Fonte: Vargas (2009).
Uma análise direta do gráfico mencionado anteriormente não é conclusiva quanto à interdependência e sobreposição de fases no projeto. Na verdade, com o desenrolar do projeto, praticamente todas as fases e grupos de processo são realizadas quase que simultaneamente, constituindo um ciclo, como é mostrado na figura a seguir:
Controle
Planejamento
Iniciação
Encerramento
Execução
Figura 1.11 – Inter-relacionameto entre as fases/grupos de processo em um projeto. Fonte: Vargas (2009).
capítulo 1
• 35
Sob outro aspecto, pode-se considerar que a realização de uma fase do projeto é também um projeto e, portanto, possui um determinado ciclo de vida e pode ser subdividida em fases. Isso significa que existe uma iniciação da fase de iniciação, um planejamento da fase de iniciação, uma execução e um controle da fase de iniciação e uma finalização da fase de iniciação, partindo, então, para a fase de iniciação do planejamento, etc. Em outras palavras, vários subprojetos em um único projeto maior. O PMBOK também evidencia esse inter-relacionamento entre as fases de uma maneira bastante clara e intuitiva, representando, em um mesmo gráfico, os ciclos de vida de todas as fases do projeto. Ciclo de vida do projeto Execução
Esforço
planejamento
Iniciação
Controle
Encerramento
Tempo
Figura 1.12 – Sobreposição das fases em um projeto. Fonte: Vargas (2009).
REFLEXÃO Em todo projeto existe uma relação estreita entre os fatores de desempenho ou performance (escopo e qualidade), custo e tempo. Isso quer dizer que é impossível predeterminar todos os fatores simultaneamente. É preciso que, com base em dois fatores, se determine o terceiro como uma função interna do projeto, ou seja, o máximo que se pode fazer é predeterminar dois fatores e calcular o terceiro como uma função dos dois anteriores. Em geral, é necessário que se conheçam, detalhadamente, dois fatores e o escopo do projeto para que se determine o terceiro fator, fechando todo o cenário do projeto.
36 •
capítulo 1
LEITURA O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na gestão de projetos organizado pelo instituto PMI e é considerado a base do conhecimento sobre gestão de projetos por profissionais da área. Histórico: Em 1983, na tentativa de documentar e padronizar as práticas que são normalmente aceitas na gerência de projetos, foi publicado o artigo "Ethics, Standards, and Accreditation Committee Final Report". A primeira edição do "A Guide to the Project Management Body of Knowledge (PMBOK Guide)" foi publicada pelo Project Management Institute (PMI) foi publicada em 1996, seguida pela segunda edição em 2000. Em 2004, o Guia PMBOK — Terceira Edição — foi publicado com maiores mudanças, considerando as edições anteriores. A quarta edição (lançada em 2008) é normatizada pelas normas ANSI/PMI 99-001-2008 e IEEE 1490-2011. A última versão do Guia PMBOK é a quinta edição que foi publicada em 2013 em Inglês. Traduções estão disponíveis em Árabe, Chinês, Francês, Alemão, Italiano, Japonês, Coreano, Português, Russo e Espanhol.Houve um avanço nos processos e tópicos do guia PMBOK de sua 4ª. Edição para sua última edição, como podemos observar no quadro a seguir. Esta atualização se fez necessária para abarcar temas e atividades que passaram a ser importantes nos projetos atuais.
GUIA PMBOK 4° EDIÇÃO (2008) Estágios Tópicos Processos
5 grupos de processos 9 áreas de conhecimento 42 processos
GUIA PMBOK 5° EDIÇÃO (2013) 5 grupos de processos 10 áreas de conhecimento 47 processos
Tabela 1.4 – Extensões do PMBOK O PMBOK atualmente define extensões ao Guia PMBOK. São elas: Extensão para Construção - Construction Extension to the PMBOK Guide — 3a Edição Extensão para Governo - Government Extension to the PMBOK Guide — 3a Edição O PMBOK também define padrões específicos ao Guia PMBOK. São eles: • Padrão para Gerenciamento de Programa - The Standard for Program Management — 2a Edição (em inglês) • Padrão para Gerenciamento de Portifólio - The Standard for Portfolio Management — 3a Edição (em inglês)
capítulo 1
• 37
Modelo de Maturidade para Gerenciamento de Projetos Organizacionais - Organizational Project Management Maturity Model (OPM3®) — 2a * Edição (em inglês) Fonte: wikipedia.org/ Project_Management_Body_of_Knowledge.
1.6 Principais Áreas de Conhecimento do Projeto segundo PMBOK As áreas do gerenciamento de projetos descrevem o gerenciamento de projetos em termos de seus processos componentes. Esses processos podem ser organizados em dez grupos integrados, segundo PMBOK, conforme descritos a seguir: • Gerenciamento/Gestão de integração do projeto A Gerência da integração do projeto é o núcleo do gerenciamento de projetos, e é composto dos processos do dia a dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo contínuo que o gerente executa para garantir que o projeto prossiga do início ao fim – é a atividade diária de completar o trabalho do projeto. O gerenciamento do projeto junta os planos de projeto, coordena atividades, recursos, restrições e suposições do projeto, e os transforma em um modelo funcional. Gerenciar a integração do projeto é garantir que os componentes do projeto precisam trabalhar juntos – e é papel do gerente de projetos fazer que isso aconteça. Exige habilidades em negociação e gerenciamento de conflitos de interesses. Também exige habilidades gerais de gerenciamento, boa comunicação, organização, familiaridade técnica com o produto, etc. Pode ser dividido em três partes: o desenvolvimento do plano do projeto, a execução do plano do projeto e o controle de mudanças no projeto. • Gerenciamento/Gestão do escopo do projeto Gerenciamento do Escopo é composto dos processos para garantir que o projeto inclua todo o trabalho exigido, e somente o trabalho exigido, para completar o projeto com sucesso.
38 •
capítulo 1
As finalidades do Gerenciamento do Escopo, conhecido também como Âmbito do Projeto, incluem a definição do trabalho necessário para concluir o projeto, servir como guia (ou ponto de referência) para determinar que trabalho não está incluído (ou não é necessário) no projeto. O escopo é o foco do projeto. O escopo do projeto difere-se do escopo do produto na medida em que o escopo do projeto define o trabalho necessário para fazer o produto, e o escopo do produto define os recursos (atributos e comportamentos) do produto que está sendo criado. Os projetos não desviam frequentemente do foco de negócios da empresa, e geralmente estão relacionados à sua atividade fim. O projeto de um sistema de informação, por exemplo, sempre tem por finalidade cobrir uma necessidade estratégica de negócio ou viabilizar a execução automatizada de um processo operacional dentro da empresa. • Gerenciamento/Gestão de tempo do projeto O objetivo da gerência do tempo de projeto é descrever os processos requeridos para o término do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades. Os principais processos desta gestão são: as Definições, Seqüenciamento, Estimativa de Recurso e Estimativa de Duração das Atividades e o Desenvolvimento e Controle do Cronograma destas Atividades. • Definições das Atividades: identificação das atividades específicas do cronograma que necessitam ser executadas para produzir os diversos tangíveis do projeto; • Sequenciar Atividades: identificação e documentação das dependências entre as atividades do cronograma; • Estimativa de Recursos de Atividade: estimativa do tipo e das quantidades dos recursos requeridos para executar cada atividade do cronograma; • Estimativa de Duração de Atividade: estimativa do período que será necessário para conclusão individual de cada atividade do cronograma; • Desenvolvimento do Cronograma: análise das sequências das atividades, suas dependências, durações e recursos requeridos para criar o cronograma; • Controle do Cronograma: controle das alterações efetuadas no cronograma;
capítulo 1
• 39
A gerência do tempo de projeto e a gerência do custo do projeto são as áreas de maior exigência dentro de um projeto, pois são as mais visíveis em sua gestão. Algumas das ferramentas clássicas de Gestão de Tempo de Projeto são o PERT/CPM e o Diagrama de Gantt. Veremos essas ferramentas mais adiante nos capítulos sobre gerenciamento do tempo. • Gerenciamento/Gestão de custos do projeto A gerência do custo do projeto agrega os processos que envolvem planejamento, estimativa, orçamento e controle de custos que serão necessários para a conclusão do projeto a partir de uma previsão orçamentária. Os processos de gerência do custo do projeto incluem: • Planejamento da gestão de custos: avaliar quais recursos e a quantidade aproximada de cada um dentro do projeto; • Estimativa de custo: desenvolver uma aproximação dos gastos com os recursos necessários para execução do projeto; • Orçamento de Custo: agregar os custos estimados de atividades ou de pacotes individuais de trabalho para estabelecer uma base de custo; • Controle de Custo: influenciar nos fatores que geram uma variação de custo e controlar as mudanças de orçamento do projeto. A gestão de custos é um processo em que se utiliza um conjunto de técnicas multidisciplinares, que nos permite compreender a origem dos custos. Este processo pode conduzir ao aumento de proventos, reduções de custos e obtenção de melhores níveis de produtividade. • Gerenciamento/Gestão da qualidade do projeto Como conceito, conhece-se a qualidade há milênios. No entanto, só recentemente ela adquiriu o status de função da gerência. Originalmente, tal função era relativa e voltada para a inspeção; hoje, as atividades relacionadas com a qualidade ampliaram-se bastante e são consideradas essenciais para o sucesso estratégico do projeto. A ampliação da abrangência da qualidade nas atividades organizacionais pode também ser percebida em responsabilidades que se agregaram à área, como qualidade ambiental e qualidade de vida, ética e valores hoje imprescindíveis e objeto de regulamentações nacionais e internacionais e de normas diversas.
40 •
capítulo 1
Isso significa que há uma crescente conscientização da sociedade a esse respeito, o que impõe o surgimento de demandas e exerce pressões complementares. Há várias classificações para diversos períodos ou eras da qualidade. Garvin (2002) estruturou-as assim: • Inspeção; • Controle estatístico da qualidade; • Garantia da qualidade; • Gestão estratégica da qualidade. Independentemente da estruturação, quando se fala sobre qualidade, cabe ressaltar que o gerenciamento da qualidade do projeto deve ser direcionado tanto para os processos de gerenciamento do projeto quanto para seu produto ou serviço final do projeto. Estes processos visam assegurar que o projeto será concluído com a qualidade desejada, satisfazendo, portanto, as necessidades do cliente e os requisitos do produto. Atualmente, a gestão da qualidade tem como preocupação básica evitar falhas. • Gerenciamento/Gestão de recursos humanos do projeto Gerenciamento de recursos humanos do projeto é uma das dez áreas de conhecimento do PMBOK (versão 5), tem como base a identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto em relação aos recursos humanos envolvidos, além da criação do plano de gerenciamento de pessoal. Obtenção dos recursos humanos necessários para terminar o projeto. Desenvolve a equipe do projeto, melhorando as competências e interação de membros da equipe para aprimorar o desempenho do projeto. Gerenciar a equipe do projeto, acompanhar o desempenho de membros da equipe, fornecimento de feedback, resolução de problemas e coordenação de mudanças para melhorar o desempenho do projeto e valorização dos profissionais envolvidos. • Gerenciamento/Gestão das comunicações do projeto Inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. Os gerentes de projetos gastam a maior parte do seu tempo se comunicando com os membros da equipe e outras
capítulo 1
• 41
partes interessadas do projeto, quer sejam internas (em todos os níveis da organização) ou externas à organização. Uma comunicação eficaz cria uma ponte entre as diversas partes interessadas envolvidas no projeto. Processos de gerenciamento das comunicações do projeto • Identificar as partes interessadas: O processo de identificação de todas as pessoas ou organizações que podem ser afetadas pelo projeto e de documentação das informações relevantes relacionadas aos seus interesses, envolvimento e impacto no sucesso do projeto. • Planejar as comunicações: O processo de determinação das necessidades de informação das partes interessadas no projeto e definição de uma abordagem de comunicação. • Distribuir as informações: O processo de colocar as informações necessárias à disposição das partes interessadas no projeto, conforme planejado. • Gerenciar as expectativas das partes interessadas: O processo de comunicação e interação com as partes interessadas para atender às suas necessidades e solucionar as questões à medida que ocorrerem. • Reportar o desempenho: O processo de coleta e distribuição de informações sobre o desempenho, incluindo relatórios de andamento, medições do progresso e previsões. • Gerenciamento/Gestão de riscos do projeto Os Riscos de projeto são um conjunto de eventos que podem ocorrer sob a forma de ameaças ou de oportunidades que, caso se concretizem, influenciam o objetivo do projeto, negativamente ou positivamente. A noção de risco é diversa, e muda consoante o enquadramento que deu origem à metodologia de gestão de risco em causa. Na metodologia Risk Mangement Guide for DOD Acquisition (2002), o risco é definido como sendo “… a atenção dirigida à ocorrência de eventos futuros, cujo exato resultado é desconhecido, e com a forma de lidar com essa incerteza, i.e., a amplitude de possíveis resultados. Inclui o planeamento, identificação e análise de áreas de risco e o desenvolvimento de opções para lidar e controlar o risco.”. Porém outro tipo de definições, igualmente abrangentes, podemos encontrar em manuais publicados pela US Project Management Institute (PMI) e pela UK Association for Project Management (APM), embora muito semelhantes entre si:
42 •
capítulo 1
• Risco – evento ou condição incerta que, se ocorrer, terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, âmbito ou qualidade – PMI, PMBOK Guide 2004, pag. 238; • Risco – determinado evento ou conjunto de circunstâncias que, ao ocorrerem, terão efeito sobre a concretização dos objetivos do projeto. A necessidade de gerenciar riscos decorre, principalmente, da consciência de existência de fatores, internos ou externos ao projeto, cujo desencadeamento, ao longo do seu ciclo de vida, podem fazer alterar o objetivo do mesmo. A identificação desses fatores e/ou das suas causas, constitui uma das etapas fundamentais, de qualquer metodologia de gestão dos riscos. O tipo de risco, a sua probabilidade de ocorrência, ou o seu impacto sobre o projeto, variam ao longo do ciclo de vida do mesmo, sendo por isso necessário proceder-se à identificação dos riscos, em todas as suas fases. • Gerenciamento/Gestão de aquisições do projeto O Gerenciamento de Aquisições do Projeto é responsável por cuidar das compras e aquisições de produtos, serviços ou resultados necessários para a realização do trabalho. A organização pode ser o comprador ou fornecedor do produto, serviço ou resultado. O Gerenciamento de Aquisições do Projeto inclui os processos de gerenciamento de contratos e de controle de mudanças necessários para administrar os contratos ou pedidos de compra. Este gerenciamento inclui, ainda, a administração de qualquer contrato emitido por uma organização externa (o comprador) que está adquirindo o projeto de uma organização executora (o fornecedor) e a administração de obrigações contratuais estabelecidas para a equipe do projeto pelos contratos. • Gerenciamento/Gestão de envolvidos do projeto ou Gerenciamento das Partes Interessadas do Projeto (adicionada na 5a Edição) O gerenciamento das partes envolvidas do projeto concentra-se em um dos elementos mais importantes da gestão de projetos, e gerencia os interessados, suas expectativas, e compromissos. Antes era parte de um processo simples dentro da área de comunicação, mas agora, é muito mais elaborada e recebe a atenção que merece. Formada por 4 partes: • Identificar as Partes Interessadas • Gerenciar o Engajamento das Partes Interessadas • Planejar o Gerenciamento das Partes Interessadas • Controlar o Engajamento das Partes Interessadas capítulo 1
• 43
A tabela a seguir resume as características de cada uma das 10 áreas de conhecimento:
ÁREA
CARACTERÍSTICAS Atividades de identificação, definição, ajuste, unificação e
INTEGRAÇÃO
coordenação entre as várias atividades da iniciação, planejamento, execução/monitoramento e encerramento.
Monitoramento e definição do que de fato está ou não incluí-
ESCOPO
do no projeto, abrangendo todo o trabalho necessário para o término do projeto, sem exceder o seu escopo
TEMPO
Detém as atividades que consistem em administrar os pro-
CUSTO
Possui atividades que visam assegurar que o projeto seja
QUALIDADE
cessos necessários ao término do projeto no prazo.
concluído em consonância com o orçamento aprovado.
Atividades que visam assegurar a conformidade do produto/ serviço do projeto em relação ao solicitado.
Refere-se às atividades que culminam na utilização efetiva dos recursos humanos do projeto, incluindo o planejamen-
RECURSOS HUMANOS
to dos recursos humanos necessários para cada fase do projeto, mobilização desses recursos (incluindo contratação externa, se necessário), desenvolvimento de competências e o efetivo gerenciamento da equipe.
44 •
capítulo 1
ÁREA
CARACTERÍSTICAS Abrange as atividades que garantem que informações do
COMUNICAÇÕES
projeto sejam planejadas, geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas
Identificação, análise, planejamento de respostas e controle
RISCOS
de riscos de um projeto para reduzir a probabilidade e o impacto dos eventos negativos e aumentar o aproveitamento das oportunidades
Contempla todas as atividades de compra ou aquisição de produtos, serviços ou resultados externos à equipe do proje-
AQUISIÇÕES
to. Quando a compra envolver licitação, o gerente de projeto deve mostrar-se mais atento a essa área de conhecimento, tendo em vista os riscos de atraso que podem envolver esse tipo de ação
Identifica pessoas, grupos e organizações que podem impactar ou ser impactadas pelo projeto, analisa as expectativas
PARTES INTERESSADAS
das partes interessadas e auxilia na montagem de estratégias de gerenciamento apropriadas para engajá-las no processo decisório e execução. Preocupa-se também com a efetiva comunicação, resolução de conflitos, identificação de problemas e satisfação das partes
Nesta disciplina, iremos explicar cada uma dessas áreas de uma forma bastante ampla, enfatizando a sua aplicação em projetos de qualquer contexto. Dessa forma, pretendemos oferecer a vocês, futuros administradores de empresas, um ferramental bastante diversificado para ser aplicado nos projetos que vocês virão a gerenciar.
capítulo 1
• 45
ATIVIDADES Desenvolvemos, abaixo, um conjunto de perguntas para que você possa fixar o conteúdo aprendido nesta unidade. Responda às perguntas abaixo utilizando como base tudo aquilo que você estudou nesta unidade, nas conexões apresentadas e utilizando o conhecimento que você já possui de vivências profissionais ou de estudos de módulos passados referentes ao mundo coorporativo. 01. É possível gerenciar um projeto dentro de uma organização por meio de boas práticas e metodologias cientificamente testadas ou só é possível gerenciar projetos fazendo uso de profissionais experientes que utilizam métodos “artísticos” para alcançar o sucesso do projeto? Explique a sua resposta. 02. O que é o PMI e qual é a principal função desta instituição? 03. Comente as principais ações do PMI no trabalho da profissionalização do gerenciamento de projetos. 04. Abaixo, marque P para projetos ou TO para trabalhos operacionais do dia a dia de uma instituição. (
) Ações para o desfile de carnaval de um determinado ano.
(
) Construção de carros em série em uma linha de b) montagem.
(
) Ações para a criação de um novo modelo de carro de uma determinada montadora.
(
) Desenvolvimento de um novo d) software de ERP para uma determinada empresa.
(
) Ações do setor de RH para a emissão de pagamentos dos funcionários de uma
determinada empresa. (
) Ações de uma empresa para determinar o processo de emissão de pagamentos
dos funcionários de uma determinada empresa. (
) Tarefas associadas a um funcionário de uma lanchonete para a confecção de lan-
ches padrões desta lanchonete.
46 •
capítulo 1
REFLEXÃO No seu desempenho profissional de um executivo, de um administrador, gestor, analista de sistemas etc., por vários momentos você irá se deparar com projetos e processos, isso por que, entre outras coisas, administrar uma empresa ou liderar uma equipe, ser encarregado de um setor ou gestor de uma célula produtiva, tudo isso consiste em administrar o dia a dia dos profissionais em suas atividades diárias, ou seja, nos trabalhos operacionais, e também em dar rumo a instituições por meio de um plano estratégico que será contemplado pela execução de vários projetos. É importante que neste momento você saiba diferenciar trabalhos operacionais de projetos e saiba que para tratar cada um desses há uma abordagem científica e sistematizada para auxiliá-lo. Neste sentido, aprendemos neste capítulo sobre o que é um projeto e sobre o PMI, que é uma instituição que luta pela profissionalização do gerente de projetos por meio da sistematização de boas práticas de abordagem ao gerenciamento de projetos. Dessa forma, sempre que você se deparar com projetos na sua vida profissional, você terá condição de identificá-los e gerenciá-los por meio das definições de uma metodologia/ processo apoiada nas boas práticas estudadas e abordadas no PMBOK. Sendo assim, o estudo desse capítulo se fez importante, porém não suficiente. Por isso, vamos em frente, ainda temos muito mais para aprender sobre gerenciamento de projetos!!
LEITURA Você pode melhorar um pouco mais o seu entendimento de gerenciamento de projetos ouvindo um pouco do que diz um dos mais reconhecidos profissionais de gerenciamento de projetos no Brasil e no mundo, o Sr. Ricardo Vargas. Nesta unidade, vamos recomendar que você ouça dois podcasts interessantes do Ricardo Vargas. O primeiro, é um podcast que fala sobre os desafios do gerenciamento de projetos. Neste, Vargas aborda as dificuldades de um projeto e parte da máxima de que não existe projeto fácil e que todos os projetos terão seus desafios e por isso que há a necessidade de um gerente de projetos. Esse podcast pode ser ouvido em: http://www.ricardo-vargas.com/ pt/podcasts/projectchallenges/ O segundo, é um podcast que fala sobre as leis de Murphy no gerenciamento de projetos. Por meio de uma alusão cômica a Murphy, Vargas explica que não há lugar para o
capítulo 1
• 47
pessimismo em projetos. Esse podcast pode ser ouvido em: http://www.ricardo-vargas.com/ wp-content/uploads/podcasts/2009/ricardo_vargas_2009_04_20_murphy_pt.mp3 O gerente de projetos O gerente do projeto é a pessoa designada pela organização responsável pela condução do projeto, com a missão de zelar para que os objetivos do projeto sejam atingidos. O gerente de projetos tem sido caracterizado por um perfil profissional com domínio e experiência especializados nos processos e nas áreas de conhecimento do gerenciamento de projetos. O trabalho do gerente de um projeto pode ser sintetizado em dois grandes elementos: • Planejar (antes) e Controlar (durante) as atividades do projeto e seu gerenciamento, conforme se pode constatar pela concentração de processos de gerenciamento de um projeto abrangendo todas os aspectos envolvidos. • Comunicar: os gerentes de projetos passam a maior parte do seu tempo tratando com os membros da equipe e outras partes interessadas do projeto. Para obter eficácia no gerenciamento, em especial na comunicação, os gerentes de projetos devem dominar habilidades interpessoais. Isso significa um longo e contínuo processo de crescimento pessoal e desenvolvimento gerencial. Segundo a psicóloga Fela Moscovici [Moscovici 1981], competência interpessoal é a habilidade de lidar eficazmente com relações interpessoais, de lidar com outras pessoas de forma adequada às necessidades de cada um e às exigências da situação. Competência interpessoal é resultante de percepção acurada e realística das situações interpessoais e de habilidades comportamentais específicas que conduzem a consequências significativas no relacionamento duradouro e autêntico, satisfatório para as pessoas envolvidas. Um terceiro componente dessa competência refere-se ao relacionamento em si, e compreende a dimensão emocional-afetiva, predominantemente. Lidar com situações interpessoais requer sensibilidade e flexibilidade perceptiva e comportamental, que significa procurar ver vários ângulos ou aspectos da mesma situação e atuar de forma diferenciada, não rotineira, experimentando novas condutas percebidas como alternativas de ação. Destacam-se as seguintes habilidades interpessoais para o gerente de projetos: • Comprometimento, responsabilidade, ética e honestidade; • Transparência, franqueza, clareza e objetividade; • Liderança, agregação, motivação e entusiasmo; • Solução de conflitos e problemas;
48 •
capítulo 1
• Negociação, influência e persuasão; • Decisão, iniciativa e proatividade; • Organização e disciplina; • Autocontrole, equilíbrio e resiliência; • Empreendedorismo; • Eficácia. O PMI mantém um Código de Ética e Conduta Profissional (Project Management Institute Code of Ethics and Professional Conduct), criado para incutir confiança à profissão de gerenciamento de projetos e auxiliar os praticantes a se tornarem melhores profissionais. Para isso, o código descreve as expectativas que os profissionais de gerenciamento de projetos têm de si e de seus colegas. Ele exige que os profissionais demonstrem compromisso com a conduta ética e profissional, sendo específico quanto à obrigação básica de responsabilidade, respeito, justiça e honestidade. Isso inclui respeitar as leis, regulamentos e políticas organizacionais e profissionais. Mais que ser um facilitador, o gerente de projetos deve fazer a diferença no bom andamento e no sucesso dos projetos. Saiba mais em: http://www.mhavila.com.br/topicos/gestao/pmbok.html
REFERÊNCIAS BIBLIOGRÁFICAS BOROVIK,Cleide; RAMIREZ, Andrea; RAMIREZ, Fernanda. Tecnotopias: arte e ciências, imagens e contexto Disponível em: . Acesso em: 16 mar. 2010. CAVALIERI, Adriane. Como se tornar um profissional em gerenciamento de projetos. São Paulo: QualityMark, 2007. FREITAS, Carlos A. V. CAPM Credential Growing in Brazil. PMI Todays. Publicado em: mar. 2009. PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania : s.n., 2004. PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania : s.n., 2008. PMI. Estudo de Benchmarking em Gerenciamento de projetos Brasil. Project Manager Institute. 2009. PMI. Project Manager Institute. Disponível em: . Acesso em: 1 jan. 2010. SOUSA, Ciclo PDCA – Um instrumento para melhoria continua. Disponível em: . Acesso em: 16 mar. 2009. WIKIPEDIA. Ciclo PDCA. Disponível em: . Acesso em: 16 mar. 2010.
capítulo 1
• 49
50 •
capítulo 1
2 Gerenciamento de Integração e Gerenciamento de Escopo
Nas unidades anteriores, começamos falando sobre definição de projetos, gerenciamento de projetos e uma breve apresentação das áreas de conhecimento de um projeto. Vimos também, sobre os ciclos de vida de produto, projeto e de gerenciamento de projetos e a partir desta unidade começamos a tratar o gerenciamento de projetos de forma mais prática, quero dizer, de forma mais aplicável, uma vez que até então estávamos tratando de conceitos por meio dos quais construímos uma base sólida em cima da qual essa parte mais “prática” poderá se sustentar. A partir deste capítulo, vamos estudar um pouco sobre como os processos dos grupos de processos já vistos anteriormente, que se dividem em 10 áreas de conhecimento e vamos mostrar as principais técnicas de algumas dessas áreas. Como visto anteriormente, o ciclo de vida de gerenciamento de projetos é dividido em 5 grupos de processos, quais são: 1. Iniciação 2. Planejamento 3. Execução 4. Monitoramento e controle 5. Encerramento Dentro de cada um desses grupos de processos, são definidos processos por meio da descrição das entradas, ferramentas/técnicas e saídas desses processos, formando, assim, as boas práticas de gerenciamento de projetos indicadas pelo PMBOK. Contudo, esses processos são organizados em 10 grandes áreas de conhecimento, a saber: integração, escopo, tempo, custo, qualidade, recursos humanos, aquisição, riscos e partes interessadas. 1. Sempre iniciaremos a explicação de cada área de conhecimento mostrando os seus objetivos e qual é a importância da área no gerenciamento de projetos. 2. Na sequência, iremos mostrar quais são os processos que compõem a área, classificando-os de acordo com o grupo de processos a que eles pertencem e fazendo uma breve descrição desses processos. 3. Por último, sempre que necessário, iremos explicar algumas das ferramentas/técnicas que consideramos mais importantes na área abordada.
52 •
capítulo 2
A primeira área a ser abordada, abre a sequência do ciclo de vida de um projeto que é o gerenciamento da integração. Vamos lá!
OBJETIVOS Com o estudo deste capítulo, iniciaremos os conteúdos pertinentes às 10 áreas de conhecimento do gerenciamento de projetos. Este capítulo portanto, trará os conceitos e atividades do gerenciamento da integração e do escopo, abrindo a lista de áreas do conhecimento descritos no PMBOK. Gerenciamento da Integração 1. Criação do Termo de Abertura 2. Ciclo padrão de planejamento e Integração do Plano de Projeto. 3. Controle e Monitoramento do Projeto 4. Controle de Mudanças 5. Encerramento de projetos Gerenciamento do escopo de um projeto 1. Definição de escopo e gerenciamento de escopo 2. Coleta de Requisitos 3. Ferramentas 4. A Declaração de Escopo 5. Definição de EAP 6. Técnicas para gerar EAP 7. Verificação do escopo 8. Controle de Mudanças do escopo
capítulo 2
• 53
2.1 Processo de Integração do Projeto O processo de integração do projeto consiste em garantir que todas as demais áreas estejam integradas em um todo único. Seu objetivo é estruturar todo o projeto de modo a garantir que as necessidades dos envolvidos sejam atendidas pelo projeto. Segundo o Guia PMBOK®, o gerenciamento da integração do projeto inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de processos de gerenciamento. O gerente do projeto age como integrador dos processos e das pessoas. Escopo Partes Interessadas
Tempo
Aquisições
Custos
Integração Riscos
Qualidade Comunicações
Recursos Humanos
Figura 2.1 – Gerenciamento da integração como área central do gerenciamento de projetos. Fonte: Vargas (2009).
Para iniciar a explicação da área de conhecimento em gerenciamento de integração, vamos falar um pouco sobre alguns stakeholders do projeto e suas principais funções. • Equipe de execução do projeto: concentra-se em completar todos os pacotes de trabalho planejados para concluir o escopo do projeto e, dessa forma, finalizá-lo. • Patrocinador do projeto: definir os objetivos, dar apoio financeiro, autorizar o projeto, delegar autoridade e defender o projeto contra perda de recursos.
54 •
capítulo 2
• Gerente do projeto: gerenciar o projeto aplicando todas as boas práticas reconhecidas e comprovadas no mercado profissional e acadêmico como práticas que funcionam na maioria dos projetos e na maior parte do tempo. No gerenciamento do projeto, o gerente de projetos também é responsável por reunir todas as peças do projeto em uma unidade coesa. Mas como o gerente de projetos consegue reunir “todas as peças” do projeto em uma unidade coesa e integrada? O que tem para ser unido e controlado de forma coesa e integrada? Para isto que existe a área de conhecimento de gerência de integração. É de responsabilidade dos processos dessa área de conhecimento identificar, definir, combinar, unificar e coordenar os diversos processos e atividades de gerenciamento de projetos, ou seja, os diversos processos e atividades das outras áreas de conhecimento. Portanto, o gerenciamento de integração é responsável por integrar todas as demais áreas de conhecimento de gerenciamento de projetos. Como vimos em unidades anteriores, as fases do ciclo de vida de gerenciamento de projetos se interagem intensamente. Então, podemos dizer que os processos que compõem essas fases também estão se interagindo intensamente. A coordenação da interação desses processos é de responsabilidade da gerência de integração, uma vez que é nessa área de conhecimento que se decide como cada área será planejada. Vamos a um exemplo trazido pelo PMBOK (2013): A gerência de integração é quem irá compor o plano de gerenciamento do projeto que irá definir e coordenar todos os planos de gerenciamento auxiliares das outras áreas de conhecimento, inclusive das áreas de gerenciamento de custo, tempo e risco, conforme citado no exemplo anterior. Por isso, voltamos a dizer que a gerência de integração é responsável pela integração dos processos entre os grupos de processos (fases) do ciclo de vida de gerenciamento de projetos para realizar os objetivos do projeto dentro dos procedimentos definidos da organização.
capítulo 2
• 55
A gerência de integração é composta pelos seguintes processos: 1. Processos de iniciação: Desenvolver o termo de abertura do projeto 2. Processos de planejamento: Desenvolver o plano de gerenciamento do projeto 3. Processos de execução: Orientar e gerenciar a execução do projeto 4. Processos de monitoramento e controle: Monitorar e controlar o trabalho do projeto Controle integrado de mudanças 5. Processos de encerramento Encerrar o projeto
2.1.1 Desenvolver o termo de abertura do projeto Este processo faz parte do grupo de processos de iniciação (ou fase de iniciação). Na verdade, este processo e o processo “desenvolver a declaração do escopo preliminar do projeto” são os únicos que compõem a fase de iniciação do ciclo de vida de gerenciamento de projetos. E ambos os processos estão sob responsabilidade da área de gerenciamento de integração. O processo “Desenvolver o termo de abertura do projeto” tem como objetivo desenvolver um documento chamado “Termo de Abertura de Projeto” ou TAP (ou, no inglês, Project Charter). Este documento serve para autorizar formalmente a abertura de um projeto e para garantir ao gerente de projetos a autoridade para aplicar os recursos da empresa no empreendimento do projeto. Portanto, este é um documento que não é escrito pelo gerente de projetos, mesmo por que é neste documento que o gerente de projetos é escolhido pelo patrocinador do projeto.
56 •
capítulo 2
CONCEITO Detalhamento desenvolvimento do termo de abertura do projeto. Entradas O processo de desenvolver o termo de abertura do projeto possui cinco entradas: 1. Declaração do trabalho do projeto: Esta entrada é uma descrição de todos os produtos e serviços que serão fornecidos pelo projeto a ser criado. Nos projetos internos à organização essa declaração pode ser feita pelo patrocinador com base nos requisitos das necessidades dos negócios (por exemplo, uma demanda de mercado, avanço tecnológico, requisito legal ou nova lei imposta pelo governo), produtos ou serviços. No entanto, para projetos externos esta declaração pode ser concedida pelo cliente através de um documento de licitação, por exemplo, solicitação de proposta, informações, preços, ou como parte de um contrato. 2. Business Case: Um business case é um documento que fornece informações necessárias do ponto de vista de um negócio, para determinar se o projeto justifica ou não o investimento. Neste documento temos a análise de custo benefício e necessidades de negócios para justificar o projeto. O cliente é o responsável por escrever o business case. O business case é criado devido a demanda de mercado onde uma empresa poderia ter verificado a necessidade de um projeto para criar um produto melhor em resposta a alguma situação imposta pelo mercado, ou devido a alguma necessidade organizacional, solicitação do cliente, avanço tecnológico, etc. 3. Contrato: Neste caso um contrato será uma entrada apenas se o projeto estiver sendo realizado por um cliente externo, assim normalmente a empresa cliente formaliza um contrato contendo algumas restrições que devem ser aceitas pela organização executora do projeto. 4. Fatores Ambientais da empresa: Os fatores ambiente são situações que podem ocorrer na organização interna ou externa que cercam ou influenciam o sucesso de um projeto. Estes fatores ambientais podem aumentar ou restringir as opções de gerenciamento de projetos e ainda podem influenciar positivamente ou negativamente no resultado deste projeto. Esses fatores ambientais podem ser: padrões governamentais ou industriais, infraestrutura organizacional, condições do mercado, entre outros. 5. Ativos de Processos Organizacionais: Os ativos de processos organizacionais são todos os ativos relacionados a processos, de quaisquer ou todas as organizações envolvidas no projeto que podem ser usados para influenciar o sucesso do projeto. Os ativos de processos organizacionais que podem influenciar no termo de abertura podem ser: Processos organizacionais padronizados, políticas e definições padronizadas de processos para uso na organização, modelos (como modelos de termo de abertura previamente definidos pela organização), informações históricas, base de conhecimento de lições aprendidas, etc.
capítulo 2
• 57
Ferramentas e Técnicas O processo desenvolver o termo de abertura do projeto possui uma ferramenta e técnica: 1. Opinião Especializada: A opinião especializada é fornecida por qualquer grupo ou pessoa que tenha conhecimento ou treinamento especializado e está disponível para ajudar na avaliação das entradas necessárias para o desenvolvimento do termo de abertura do projeto. A opinião do especialista é aplicada a qualquer detalhe que seja técnico ou de gerenciamento durante o processo de termo de abertura. Essa opinião especializada pode estar disponível através de outras unidades dentro da organização, consultores, clientes, especialistas no assunto, etc.
Saídas O processo desenvolver o termo de abertura do projeto possui uma saída: 1. Termo de Abertura do Projeto: Como foi visto até o momento, o termo de abertura é onde estão documentadas todas as necessidades do negócio, o entendimento das necessidades do cliente, informações sobre o novo produto, serviço ou resultado a ser satisfeita pela organização executora. O termo de abertura gerado pode conter: 1. Propósito ou justificativa do projeto; 2. Os objetivos mensuráveis do projeto e critérios de sucesso relacionados; 3. Requisitos de alto nível; 4. Descrição do projeto em alto nível; 5. Riscos de alto nível 6. Resumo do cronograma de marcos; 7. Resumo do orçamento; 8. Requisitos para aprovação do projeto; 9. Gerente de projeto designado, responsabilidade e nível de autoridade; 10. Nome e autoridade do patrocinador ou outra pessoa (ou pessoas) que autoriza(m) o termo de abertura do projeto. Pode-se notar também que o termo de abertura do projeto não possui nada muito detalhado, ele é um documento formal mais abstrato que autoriza o projeto e dá informações importantes que servirão para guiar o restante do projeto. Leia mais em: Gerenciamento da Integração segundo o PMBoK http://www.devmedia. com.br/gerenciamento-da-integracao-segundo-o-pmbok/27359#ixzz3lplFrPmw
58 •
capítulo 2
2.1.2 Desenvolver o plano de gerenciamento do projeto Este processo pertence ao grupo de processos de planejamento e tem por objetivo definir, coordenar e integrar todos os planos auxiliares de planejamento (os outros planos das outras 8 áreas de conhecimento) em um plano de gerenciamento do projeto que definirá como o projeto será executado, monitorado, controlado e encerrado. Nesta unidade, iremos explicar cada plano de gerenciamento que compõe o plano de gerenciamento do projeto. Então, é função deste processo organizar a confecção do plano de gerenciamento de cada grande área de conhecimento como planejamento de escopo, custo, tempo, risco, recursos humanos, qualidade, aquisições e comunicações.
2.1.3 Orientar e gerenciar a execução do projeto Este processo pertence ao grupo de processos de execução. O trabalho determinado na declaração do escopo do projeto (documento este que ainda não vimos, pois o processo responsável pela sua geração está na área de conhecimento de gerência de escopo, porém podemos entender por enquanto que este trabalho está declarado nos documentos de termo de abertura do projeto e documento de declaração do escopo preliminar do projeto) deve ser realizado. Então, realizar este trabalho é o objetivo deste processo de integração. (VIEIRA, 2007). O gerente deve tomar muito cuidado neste processo para que os membros da equipe executora não implementem funcionalidades a mais do que aquelas declaradas no escopo do projeto. Pois, aumentar o escopo do projeto significa um acréscimo de custo e tempo que podem ser indesejados pelo patrocinador/ iniciador do projeto. Para realizar este trabalho, algumas ações devem ser tomadas, a saber: executar as atividades planejadas; usar recursos financeiros para executar o objetivo do projeto; formar, treinar e gerenciar os RH do projeto; obter cotações; selecionar fornecedores; gerenciar e obter recursos; implementar normas e métodos planejados; criar, controlar verificar e validar as entregas do projeto; gerenciar riscos; gerenciar fornecedores; implementar alterações; coletar dados e relatar custos, cronograma, progresso técnico e informações gerais sobre o andamento do projeto; coletar e documentar as lições aprendidas. (PMBOK, 2008).
capítulo 2
• 59
2.1.4 Monitorar e controlar o trabalho do projeto Este é um processo do grupo de processos de monitoramento e controle e tem por objetivo gerenciar as alterações no planejamento do projeto à medida em que elas ocorrem. São atividades desse processo: comparação do desempenho real do projeto com o plano de gerenciamento do projeto (linhas base); avaliação do desempenho do projeto; análise, acompanhamento e monitoramento de riscos; manutenção de base de informações relativas ao produto do projeto; fornecimento de informações para dar suporte a relatórios de andamento, medições de progresso e previsões; monitoramento de implementações de mudanças aprovadas. Esse processo é particularmente importante, pois por meio dele é que as mudanças solicitadas serão discutidas, controladas e aprovadas. Muitas vezes, os stakeholders não conseguem visualizar o impacto que determinadas solicitações de alteração irão gerar no projeto. Então, este processo nos serve para que essas solicitações de alteração sejam discutidas com a seriedade merecida e, uma vez aprovadas, seja então comunicado a todos de forma efetiva e incluída no planejamento do projeto.
2.1.5 Realizar o controle integrado de mudanças Este processo faz parte do grupo de processos de monitoramento e controle e define as atividades necessárias para a avaliação, aprovação/rejeição de todas e quaisquer mudanças solicitadas no projeto. Há algumas áreas de aplicação como, por exemplo, a área de tecnologia de informação, na qual essas mudanças acontecem muito rapidamente e os impactos, na grande maioria das vezes, são mal analisados. Então, o controle integrado de mudanças se preocupa em analisar os motivos geradores das mudanças para analisar se elas são realmente necessárias e, posteriormente, gerenciar as alterações no momento em que elas acontecem. São ações desse processo, entre outros: identificação da ocorrência ou necessidade de ocorrência de uma determinada mudança; revisão e aprovação das mudanças solicitadas; gerenciamento das mudanças aprovadas; manutenção da integridade das linhas de base; revisão e aprovação de todas as ações preventivas e corretivas; controle e atualização de escopo, custo e tempo; documentação do impacto total das mudanças solicitadas; validação do reparo do defeito; controle de qualidade do projeto.
60 •
capítulo 2
2.1.6 Encerrar o projeto ou fase Este processo faz parte do grupo de processos de encerramento. O processo Encerrar o projeto envolve a realização da parte de encerramento do projeto do plano de gerenciamento do projeto. Em projetos com várias fases, o processo Encerrar o projeto encerra a parte do escopo do projeto e as atividades associadas, aplicáveis a uma determinada fase. (PMBOK, 2004). O encerramento do projeto é particularmente importante, pois é aqui que as lições aprendidas são revistas e se faz um “balanço final” sobre o projeto que está terminando (ou fase do projeto que está terminando). Em projetos de TI, dada a sua característica de curto prazo de implementação e alta instabilidade de requisitos, consolidar as lições aprendidas e os ativos conseguidos com o projeto é importantíssimo, principalmente quando tratamos de reaproveitamento de códigos, padrões de desenvolvimento e arquiteturas. Um bom encerramento de projeto significa a consolidação de todos esses ativos para que eles possam ser recuperados e utilizados facilmente em projetos futuros. Este processo possui dois procedimentos administrativos: encerramento administrativo e encerramento de contratos.
COMENTÁRIO O processo de integração tem, portanto, o desafio de garantir que todas as demais áreas estejam integradas em um todo único e deve estruturar todo o projeto de modo a garantir que as necessidades dos envolvidos sejam atendidas pelo projeto.
2.2 Gerenciamento de Escopo Logo após a aprovação do projeto e a formalização de sua abertura deve-se perguntar: o que vamos ter que fazer para atingir estes objetivos? De fato, a definição sobre o que fazer é de enorme relevância para que o projeto seja bem sucedido em seus objetivos e deve ser feita adequadamente. Na verdade, não só a definição de que tipo de trabalho deve ser realizado, mas também como garantir que o trabalho seja feito é de responsabilidade da área de gerenciamento de escopo. capítulo 2
• 61
O gerenciamento de escopo trata dos limites do projeto, estabelecendo tudo o que está dentro do projeto e tudo o que está fora do projeto (às vezes, especificar o que está fora é quase tão importante do que especificar o que está dentro, por causa dos requisitos de contexto e requisitos não funcionais dos softwares). Definir corretamente o escopo é uma das partes mais importantes do gerenciamento de projeto, pois se pensarmos em qualidade como um conceito relacionado com o atendimento dos requisitos dos stakeholder, então determinar muito bem esses requisitos é o primeiro passo para entregar um produto/ serviço de qualidade e ter sucesso no projeto. A determinação do que exatamente faz parte ou não faz parte do projeto e a identificação das necessidades do cliente e tradução dessas necessidades em requisitos é uma atividade complexa (e dependendo da área do projeto, essa complexidade pode ser realmente muito alta e se transformar em ponto crítico de sucesso do projeto). Gerenciamento do escopo em Tecnologia da Informação Em TI, a determinação do que exatamente faz parte, ou não faz parte do projeto e a identificação das necessidades do cliente e tradução dessas necessidades em requisitos é uma atividade extremamente complexa, pois produtos de softwares são abstratos, e definir algo abstrato logo nas primeiras fases do projeto (ponto em que se faz necessário a definição do escopo) é realmente uma tarefa difícil.
Para garantir que o escopo do projeto estará bem documentado e prevendo tudo o que o projeto deve conter para que o produto/serviço final exceda as expectativas do iniciador/patrocinador, a área de gerência de escopo conta com 3 processos de planejamento e 2 de monitoramento e controle, a saber:
PROCESSOS DE PLANEJAMENTO PROCESSOS DE MONITORAMENTO E CONTROLE Coletar os requisitos Definir o escopo Criar EAP
Verificar o escopo Controlar o escopo.
Tabela 2.5 – Processos de Gerenciamento de Escopo.
62 •
capítulo 2
No decorrer deste capítulo, detalharemos todos s processos de gerenciamento de escopo, a começar pela coleta de requisitos.
2.2.1 Coletar os requisitos Este processo tem como objetivo: definir e documentar as necessidades das partes interessadas para alcançar o objetivo do projeto. (PMBOK, 2008). Porém, é necessário distinguir entre os dois tipos de escopo, quanto se trata de gerenciamento de projetos. O escopo, em projetos, pode ser entendido de duas formas: 1. Escopo do produto: descreve tudo o que o produto tem, ou seja, busca definir o produto em termos de suas funcionalidades. 2. Escopo do projeto: delimita e define todo o trabalho que precisa ser feito (principalmente em termos de gerenciamento) para que o escopo do produto seja atendido. Com esse entendimento sobre escopo, é necessário visualizar a definição dada para este processo de uma forma mais ampla. Ou seja, o escopo objetiva definir e documentar, junto às partes interessadas, as funções e funcionalidades do produto e do projeto. (PMBOK, 2008). O processo de coleta de requisitos gera como resultado todos os requisitos analisados do produto e do projeto e serve de base para a confecção da Estrutura Analítica do Projeto e para a elaboração dos planejamentos de tempo, custo e qualidade. Levantamento de Requisitos em Projetos de TI Considerando a definição de escopo mais ampla como definir e documentar, junto às partes interessadas, as funções e funcionalidades do produto e do projeto, o gerenciamento de escopo trata de tudo o que envolve a criação dos produtos e sobre todos os processos utilizados para criá-los. Sendo que tudo deve ser baseado nos requisitos do cliente. Em projetos de TI, a definição do escopo é razoavelmente complexa principalmente em projetos de desenvolvimento de novos softwares, quando se faz necessária a transformação das necessidades dos stakeholders em requisitos formais que deverão ser implementados pelo software.
capítulo 2
• 63
Para resolver essas complexidades, a engenharia de software propõe o processo de engenharia de requisitos, que, segundo Sommerville (2003), é composto por quatro atividades básicas: estudo de viabilidade, obtenção e análise de requisitos, especificação de requisitos, validação de requisitos. Neste processo de engenharia de requisitos, no momento de determinação do escopo do software, é necessário se atentar aos seguintes pontos: 1. Contexto: a) Em qual contexto o software se encaixa? Há um sistema maior que o engloba? b) As restrições impostas pelo contexto do software. 2. Objetivos da informação: a) Os dados serão produzidos como saída do software e visto pelos usuários finais. b) Os dados que serão a entrada do sistema. 3. unções e desempenho a) As funções que o software deverá ter para transformar as entradas em saídas interessantes para o usuário final (processar os dados). b) Requisitos não funcionais como desempenho, usabilidade, manutenibilidade e etc. (PRESSMAN, 2006). Com o escopo bem definido e os requisitos do software claros e consistentes, forma-se o primeiro passo para entregar um produto/serviço de qualidade, uma vez que o conceito de qualidade esta relacionado em atender ou superar as expectativas e necessidades do cliente por meio dos requisitos implementados no software. Então, entender os requisitos do software é condição sine qua non para o desenvolvimento de um produto de qualidade. Ainda, uma definição de escopo correta, também permite uma análise consistente do tempo envolvido na conclusão do projeto, uma vez que os processos de gerenciamento do tempo partem da EAP que contém todo o escopo do projeto.
Para coletar os requisitos de um produto e, consequentemente de um projeto, existem diversas técnicas (PMBOK, 2008): • Entrevistas; • Questionários; • Grupos focais (grupos de consumidores monitorados que são convidados a debaterem as características de um determinado produto); • Conversas informais;
64 •
capítulo 2
• Benchmarking com outros projetos (tomar por base requisitos que Foram atendidos por outros projetos realizados anteriormente); • Técnica Delphi (um grupo seleto de especialistas responde questionários e debate sobre os requisitos); • Opiniões técnicas especializadas. Um aspecto de importante observação sobre a coleta de requisitos é que os requisitos não têm origem somente nos clientes. É comum que os próprios clientes não tenham consciência sobre que requisitos devem ser atendidos para sucesso de um projeto. Dessa forma, é importante consultar outras fontes, como membros experientes da equipe ou mesmo outros colaboradores que não façam parte da equipe no projeto atual, mas tenham experiências anteriores. Porém, independente da origem dos requisitos eles devem ser claramente estabelecidos no projeto e é aconselhável que possam ser rastreados, associando cada um a sua fonte. Para esse objetivo, um recurso interessante é a construção de uma matriz de rastreabilidade, representada na tabela 2.2. REQUISITO 1 REQUISITO 2 REQUISITO 3 REQUISITO N
STAKEHOLDER 1
STAKEHOLDER 2
STAKEHOLDER 3
Conforto
Segurança
Preço baixo
Potência
Desempenho
Conforto
Aceleração
Design
Segurança
Tabela 2.6 – Exemplo de matriz de rastreabilidade.
Uma matriz de rastreabilidade define e controla o que será incluído ou não no projeto e inclui somente os artefatos para gerenciar o escopo do projeto e não do produto. Além disso, é necessária uma verificação constante dessa matriz para ter certeza que todo o trabalho necessário está sendo realizado e para impedir a realização de trabalho extra que não faça parte do projeto (PMBOK, 2008). A tabela 2.2 é um exemplo simplificado de uma matriz de rastreabilidade. Este recurso pode apresentar outros itens, tais como: • Prioridade; • Fase do Projeto; • Descrição do Requisito; • Critérios de Aceitação; • Dependências Externas;
capítulo 2
• 65
• Data da Criação do Requisito; • Data da última alteração; • Responsável pela última alteração; • Motivo da última alteração; • Situação do requisito. Além da matriz de rastreabilidade, o processo de coleta de requisitos também possibilita a construção do documento de requisitos, que descreve como cada requisito atende a(s) necessidade(s) do negócio e qual necessidade será atendida dentro dos objetivos do projeto. Ainda, os requisitos devem ser descritos sem gerar dupla interpretação e sempre que possível, usar critérios de aceitação mensuráveis retirando qualquer subjetividade da avaliação. Na fase do planejamento do escopo do projeto, além da cultura organizacional, infraestrutura, ferramentas, recursos humanos, políticas de pessoal e condições de mercado, a sustentabilidade ambiental do projeto também deve ser analisada. As questões que precisam ser levantadas nessa fase podem ser: o projeto irá afetar o meio ambiente no seu entorno? Quais são as opções de mudanças no escopo do projeto o gerente poderá lançar mão, caso algum impacto ambiental negativo afete sobremaneira o projeto? É fundamental que a área do gerenciamento ambiental esteja prevista inclusive na EAP para que nenhum dos processos dessa área seja esquecido Este livro segue a metodologia sugerida pelo guia PMBOK, 2008. Tal Guia de Gerenciamento de Projetos fornece as principais referências para o gerenciamento de projetos. Para tanto, ele mapeia as áreas de conhecimento indispensáveis para atingir esse fim e desenvolve um capítulo para cada uma dessas áreas. Porém, o Guia não desenvolve um capítulo para tratar do gerenciamento ambiental nos projetos e, para, complementar as práticas do Guia, o Professor Doutor Ricardo Vargas escreveu um artigo com orientações para observação dos requisitos dessa natureza.
AUTOR Ricardo Viana Vargas é um especialista em gerenciamento de projetos, portfólio e riscos com diversas certificações. Foi, nos últimos 18 anos, responsável por mais de 80 projetos de grande porte em diversos países, nas áreas de petróleo, energia, infraestrutura, telecomuni-
66 •
capítulo 2
cações, informática e finanças, com um portfólio de investimentos gerenciado superior a 20 bilhões de dólares. Atualmente, é diretor do Grupo de Práticas de Projetos Sustentáveis do Escritório de Serviços de Projetos das Nações Unidas (UNOPS, na sigla em inglês) em Copenhagen, na Dinamarca. Seu trabalho tem como foco a melhoria da gestão dos projetos humanitários, de construção da paz e de desenvolvimento de infraestrutura em dezenas de países, como Haiti, Afeganistão, Iraque e Sudão do Sul. Site: http://www.ricardo-vargas.com/pt/
Para reduzir custos e impactos negativos devem-se incorporar requisitos ambientais desde o início de um projeto. Além disso, deve-se levar em conta aspectos prioritários, tais como: características físicas e estruturais, condições ambientais locais e regionais, requisitos legais, disponibilidade de recursos. Para atender aos requisitos ambientais é necessário se perguntar: 1. O projeto está obrigado por lei a apresentar o Licenciamento Ambiental? a) Como proceder em caso positivo? 2. Quais os procedimentos a serem adotados? 3. Quais os órgãos competentes para fiscalizar esses procedimentos? 4. Quais os prazos legais que devem ser observados? 5. Quem são os profissionais que têm competência legal e técnica para desenvolver o EIA/RIMA? 6. Quanto custará ao projeto?
CONCEITO Definição Licenciamento ambiental Procedimento administrativo pelo qual o órgão ambiental competente licencia a localização, instalação, ampliação e a operação de empreendimentos e atividades utilizadoras de recursos ambientais, consideradas efetiva ou potencialmente poluidoras ou daquelas que, sob qualquer forma, possam causar degradação ambiental, considerando as disposições legais e regulamentares e as normas técnicas aplicáveis ao caso.
capítulo 2
• 67
CONCEITO Definição EIA/RIMA Segundo o art. 3º da Resolução CONAMA nº 237/97, a Licença Ambiental para empreendimentos e atividades consideradas efetiva ou potencialmente causadoras de significativa degradação do meio dependerá de prévio Estudo de Impacto Ambiental e respectivo Relatório de Impacto sobre o Meio Ambiente (EIA/RIMA), ao qual se dará publicidade, garantida a realização de audiências públicas, quando couber, de acordo com a regulamentação. Por outro lado, o órgão ambiental competente, verificando que a atividade ou empreendimento não é potencialmente causador de significativa degradação do meio ambiente, definirá os estudos ambientais pertinentes ao respectivo processo de licenciamento.
ATENÇÃO A área de conhecimento em gerenciamento ambiental do projeto inclui os processos internos e externos e as consequentes atividades desses processos que são necessárias para que o projeto cause o mínimo impacto possível ao Meio Ambiente onde ele será desenvolvido. O referencial teórico para a consolidação desse gerenciamento ambiental é o conceito de sustentabilidade ambiental da Comissão Mundial Sobre Meio Ambiente e Desenvolvimento (Organização das Nações Unidas – ONU), que no Relatório Brundtland de 1987 definiu o Desenvolvimento Sustentável como sendo “O desenvolvimento que satisfaz as necessidades presentes, sem comprometer a capacidade das gerações futuras de suprir suas próprias necessidades”. Deste modo, o conceito de sustentabilidade ambiental é o foco desse gerenciamento, em que todas as demais áreas do gerenciamento do projeto serão transversalmente afetadas.” (disponível em http://www.ricardo-vargas.com/pt/articles/gerenciamento-ambiental)
Uma vez que a etapa de coleta de requisitos é encerrada, pode-se partir para a etapa de definição de escopo. Definir o escopo A definição de escopo envolve a preparação de uma declaração de escopo detalhada para o projeto, que envolve a identificação de qual o trabalho a ser realizado e os responsáveis, o dimensionamento dos pacotes de trabalho, ou
68 •
capítulo 2
work packages (WP) e a criação de um dicionário que explique os aspectos técnicos da EAP. Entre os aspectos positivos da definição de escopo estão: • obriga os stakeholders a concordarem com as fronteiras do projeto; • durante a execução, permite identificar as mudanças que estão fora do escopo do projeto e requerem renegociação do contrato original; • ajuda a estabelecer critérios que mensurem o sucesso do projeto, • de forma que todos os envolvidos os conheçam e estejam de acordo; • auxilia a compreensão da equipe de projeto sobre as abordagens e métodos utilizados no projeto. É importante destacar que como o escopo de projeto serve de base para várias decisões no projeto, deve-se ter muito cuidado com o que está incluído e o que não está antes de iniciar a execução. A definição correta sobre o que deve estar incluído no escopo do projeto e também seu gerenciamento é ilustrado na história representada na figura 2.2:
Como o cliente explicou...
Como o projeto foi documentado...
Como o lider de projeto entedeu...
Como o analista projetou...
Como o programador construiu...
Que funcionalidades foram instaladas...
Como o cliente foi cobrado...
Como foi mantido...
Como o Consultor de negócios descreveu...
O que o cliente realmete queria...
Figura 2.2 – Exemplo do mau gerenciamento de escopo em um projeto de software. Fonte: imagem cedida por Creative Commons, disponível em: http://www.projectcartoon.com
capítulo 2
• 69
No exemplo da figura 2.2 é possível perceber que o mau gerenciamento do escopo leva o projeto a desperdiçar recursos e não atingir seus objetivos, tornando o cliente insatisfeito. Isto acontece porque o escopo de trabalho é o “coração” do gerenciamento de projetos, sendo que todas as outras áreas, em algum ponto dependem de sua correta definição. A declaração de escopo deve estar clara inclusive em termos contratuais, pois o cliente pode esperar que o projeto apresente mais do que está sendo feito ou a equipe pode estar trabalhando em algo que não agrega valor e que o cliente não precisa, por isso torna-se fundamental definir corretamente o escopo. A definição de um escopo deve conter os fatores mostrados na figura 2.3 Objetos do Projeto; Premissas e Retrições; Lista das entregas e seus requisitos; Estrutura Analítica do Projeto; Fora do escopo do projeto (O que não incluido no projeto); Critérios de aceitação do projeto.
Figura 2.3 – Elementos da declaração do escopo.
Os objetivos do projeto são critérios quantificáveis que devem ser encontrados no projeto para que ele seja considerado um sucesso. Os objetivos do projeto devem incluir, no mínimo, custo, cronograma e medidas de qualidade. Os objetivos do projeto devem ter um atributo (por exemplo, custo), uma medida (por exemplo, US$ dólar) e um valor absoluto ou relativo (por exemplo, menos que 1,5 milhões). Objetivos não quantificáveis (por exemplo, “satisfação dos clientes”) representam alto risco para um término do projeto com sucesso. As restrições do projeto s restrições são fatores que limitarão as opções da equipe de gerência do projeto. Por exemplo, um orçamento pré-definido é uma
70 •
capítulo 2
restrição que na maioria das vezes limita as opções da equipe com relação a escopo, pessoal e prazos. Quando um projeto é desenvolvido sob contrato, as cláusulas contratuais serão geralmente restrições. Outro exemplo é uma exigência de que o produto do projeto seja sustentável do ponto de vista social, econômico e ambiental, o que trará repercussões no escopo, na equipe e no prazo do projeto. Caso haja quebra de contrato ou o projeto gaste mais que o orçamento previsto, há risco de cancelamento do projeto. Premissas ou suposições são fatores que, para os propósitos do planejamento, são consideradas verdadeiros, reais, ou certos. As premissas afetam todos os aspectos do planejamento do projeto e são parte da elaboração progressiva do projeto. As equipes de projetos frequentemente identificam, documentam e validam premissas como parte de seu processo de planejamento. Por exemplo, se a data na qual uma pessoa chave estará disponível para o projeto é incerta, a equipe pode assumir uma data de início específica. Podem ser organizacionais, ambientais e externas. Podem ser consideradas como as “cláusulas contratuais” que se não forem cumpridas, comprometem o sucesso do projeto, ou aquilo que você quer exigir das partes interessadas. Por exemplo: Disponibilidade de 50% do tempo do cliente durante os testes. Se o cliente não estiver disponível 50% do tempo, o prazo, provavelmente, não será cumprido. A lista das entregas e seus requisitos envolvem definição de subprodutos. Subprodutos do projeto constituem uma lista de nível sumário dos subprodutos que entregues total e satisfatoriamente indicam o término do projeto. Por exemplo, os principais subprodutos para um projeto de desenvolvimento de software devem conter o código de trabalho do computador, um manual do usuário e um tutorial interativo. Quando conhecidas, exclusões devem ser identificadas, mas alguma coisa não incluída explicitamente está excluída implicitamente. A estrutura analítica do projeto (EAP) será tratada detalhadamente e separadamente. Em projetos de tecnologia da informação, especificar o que está fora do escopo é quase tão importante quanto especificar o que está dentro, devido aos requisitos de contexto e requisitos não funcionais dos softwares).
capítulo 2
• 71
Por último, dentro da definição ou declaração de escopo, temos a definição de critérios, inclusive requisitos de desempenho e condições essenciais, que devem ser atendidos antes que as entregas do projeto sejam aceitas
Técnicas e ferramentas para definição do escopo 1. Análise do produto. A análise do produto envolve desenvolver um melhor entendimento do produto do projeto. Isso inclui técnicas como a análise de decomposição do produto, engenharia de sistemas, engenharia de valor, análise de valor, análise de funções e desdobramento das funções de qualidade. 2. Análise de custo/benefício. A análise de custo/benefício envolve estimar custos tangíveis e intangíveis (outlays – gastos) e benefícios (returns - receitas) das várias alternativas de projeto e produto e, então, usar medidas financeiras tais como retorno de investimento ou período de reembolso para avaliar a qualidade relativa das alternativas identificadas. 3. Identificação de alternativas. Este é um termo genérico para qualquer técnica usada para gerar diferentes abordagens do projeto. Existem várias técnicas de gerenciamento freqüentemente usadas aqui, sendo as mais comuns o brainstorming e o lateral thinking (pensamento lateral). 4. Avaliação especializada. Uma avaliação especializada é, frequentemente, requerida para avaliar as entradas desse processo. Tal habilidade pode ser provida por um grupo ou indivíduo com conhecimento especializado ou treinamento, e está disponível em várias fontes, por exemplo: • Outras unidades dentro da organização. • Consultores. • Partes envolvidas, incluindo clientes. • Associações profissionais e técnicas. • Grupos industriais.
Estrutura Analítica do Projeto – EAP A EAP é a estrutura analítica do projeto. Embora em um primeiro momento o nome em português desta ferramenta possa parecer estranho, quando analisamos o nome em inglês fica mais fácil entender qual é a proposta desta ferramenta.
72 •
capítulo 2
WBS é o termo em inglês referente a EAP e significa work breakdown structure, que quer dizer: Work: esforço físico ou mental sustentável para transpor obstáculos e atingir um objetivo; Breakdown: divisão em partes ou categorias. Decompor em partes menores; Structure: algo organizado de forma padronizada ou formalizada. Assim fica mais fácil de entender que a EAP e a decomposição (breakdown) hierárquica (structure) orientada a entrega do trabalho (work) do escopo do projeto. Esses trabalhos devem ser executados pela equipe do projeto para atingir os objetivos do projeto. A decomposição dos trabalhos em partes menores serve para torná-los mais gerenciáveis. A EAP é uma ferramenta gráfica, então a decomposição hierárquica do trabalho do projeto acontece por meio de retângulos e interligações desses retângulos para formar a hierarquia de trabalho. Para a criação de uma EAP é comum o uso da técnica de decomposição que sugere a subdivisão das entregas de trabalhos em componentes menores e mais facilmente gerenciáveis de forma que, em processos futuros do ciclo de vida de gerenciamento de projetos, o tempo e o custo possam ser estimados de forma confiável. Este último nível de entrega de trabalho é chamado de pacote de trabalho. Uma boa prática para se desenhar uma EAP é partir de um retângulo principal que recebe o nome do projeto; em seguida, como filhos desse retângulo, são desenhadas as fases do projeto, e, como filhos dessas fases, são desenhados os pacotes de entregas intermediários e, por fim, como filhos dos pacotes intermediários, são desenhados os pacotes de trabalho que devem ser entregues, como mostra a figura 2.2. A decomposição do trabalho total do projeto normalmente envolve as seguintes atividades: identificar as entregas de trabalhos relacionadas; estruturação e organização da EAP; decomposição dos níveis mais altos da EAP em níveis mais baixos; desenvolvimento e atribuição de códigos de identificação aos componentes da EAP; verificar se o grau de decomposição é necessário e suficiente.
capítulo 2
• 73
CONEXÃO Este vídeo, de Ricardo Vargas, explica a construção da EAP de maneira bastante didática. Endereço: https://www.youtube.com/watch?v=TS9eciG-Ddw
Produto Software Versão 5.0
Ciclo de Vida do Projeto
Gerenciamento do projeto
Requisitos do produto
Projto detalhado
Construção
Integração e teste
Planejamento
Software
Software
Software
Reuniões
Documentação do usuário
Documentação do usuário
Documentação do usuário
Documentação do usuário
Administração
Materiais dos programas de treinamentos
Materiais dos programas de treinamentos
Materiais dos programas de treinamentos
Materiais dos programas de treinamentos
Software
Figura 2.4 – Exemplo simplificado de uma EAP organizada por fases de um projeto de desenvilvimento de software (adaptado de PMBOK, 2008).
Entretanto, até onde se deve “quebrar” o trabalho do projeto na EAP, ou seja, qual seria o tamanho ideal do pacote de trabalho, o quão específico ele pode ser? Segundo Ricardo Vargas, há uma regra de ordem prática chamada “4/40 e 8/80” que significa que um pacote de trabalho deve ter no mínimo entre 4-8h e no máximo entre 40-80h. Já para o professor Josué Silva, referenciado no link de multimídia a seguir, o momento de parar de decompor a atividade é quando é possível lhe atribuir uma pessoa responsável. Outro ponto interessante de se notar é que há duas formas de se orientar a construção de uma EAP: EAP orientada a entrega e EAP orientada a tarefas. A primeira diz respeito a organizar a EAP orientada a pacotes de entrega, ou seja, entregáveis. A segunda diz respeito a organizar a EAP orientada a tarefas, ou seja, a atividades que devem ser executadas para entregar o projeto.
74 •
capítulo 2
CONEXÃO Técnicas para geração da EAP - https://www.youtube.com/watch?v=qQQ5RHuDA6A
Para que não haja nenhum tipo de ambiguidade ou mais de uma interpretação, quando da elaboração de uma EAP, é necessária a criação de um dicionário, de forma que todos os termos descritos dentro das caixas da EAP sejam claros. O dicionário da EAP pode servir como parte de um sistema de autorização de trabalho descrevendo para os integrantes da equipe cada componente da estrutura analítica do projeto e pode ser usado para controlar quando um trabalho específico é realizado de modo a evitar aumento do escopo e aumento da compreensão das partes interessadas sobre o esforço necessário para cada pacote de trabalho. A figura 2.3 ilustra um exemplo de dicionário de EAP. 1.1.6
1.1.7 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.3 1.2.4 1.3
Processos de definição e documentação das decisões de compras do projeto especificando a abordagem e identificando fornecedores em potecial. O gerenciamento de custos inclui processos envolvidos em estimativa, orçamentação e controle de Gestão de custos custos de modo que seja possível concluir o projeto dentro do orçamento aprovado. Execução do projeto Fase Nessa etapa será realizada análise junto a usuários Análise do sistema para definição da customização a ser realizada além da definição de ferramentas e distribuição da equipe. Etapa de desenvolvimento de rotinas e programas Desenvolvimento e customização definidos para customização do sistema. Efetuar aquisições Compra de equipamentos e contratação de um DBA. Nessa etapa será realizada a implantação e confiMontagem da infraestrutura guração de software e hardware para a implantação do sistema. Nessa etapa será realizado a implantação do novo Implantação do controle de estoque sistema. Nessa etapa será definido o cronograma de treinaTreinamento mentos, elaboração e distribuição dos manuais e a execução dos treinamentos. Auditoria dos processos e encerramento oficial do Encerramento projeto. Planejamento e execução do controle do monitoraAcompanhamento mento do projeto. Gestão de compras e aquisições
Tabela 2.7 –
capítulo 2
• 75
Verificação do escopo Verificação do escopo é o processo de obter o aceite formal do escopo do projeto pelas partes envolvidas (patrocinador, cliente, freguês e etc.). Isto exige uma revisão dos produtos e resultados do trabalho para garantir que tudo foi completado correta e satisfatoriamente. Se o projeto terminar mais cedo, o processo de verificação do escopo deve estabelecer e documentar o nível e extensão da complexidade. A verificação do escopo difere do controle da qualidade já que é fundamentalmente relacionada com a aceitação do resultado do trabalho enquanto o controle da qualidade é fundamentalmente relacionado com a exatidão dos resultados do trabalho. Assim para o mesmo trabalho executado busca-se tanto a exatidão quanto a aceitação do escopo.
REFLEXÃO A verificação do escopo é um processo contínuo que visa garantir que todas as atividades sejam realizadas corretamente e satisfatoriamente.
Uma das técnicas utilizadas para verificação do escopo é a inspeção. Essa técnica inclui atividades tais como medição, exames e testes incumbidos de determinar se os resultados estão de acordo com as exigências. As inspeções são, diferentemente, chamadas de revisões, revisões de produto, auditoria, e ensaios (walk-throughs); em algumas áreas de aplicação esses diferentes termos têm significado estreito e específico. A saída essencial da verificação do escopo é o documento de aceitação formal, que consiste na documentação de que o cliente ou patrocinador aceitou o produto do projeto ou da fase deve ser preparada e distribuída. Tal aceitação pode ser condicional, especialmente no fim de uma fase.
Controle do Escopo O controle de mudanças do escopo consiste em: influenciar os fatores que criam mudanças no escopo para garantir que as mudanças sejam discutidas e combinadas; determinar que uma mudança no escopo ocorreu, e gerenciar as mudanças efetivas quando ocorrerem. O controle das mudanças do escopo
76 •
capítulo 2
deve se integrar aos demais processos de controle (controle de prazo, controle de custo, controle de qualidade, e outros) (PMBOK, 2008). O controle de escopo geralmente faz uso do sistema de controle de mudanças, que define os procedimentos necessários para efetuar mudanças no escopo do projeto e inclui a documentação e os níveis de aprovação necessários em cada caso. Para realizar este tipo de controle é preciso ter uma clara visão sobre os detalhes do escopo do projeto (envolvendo o plano de gerenciamento de escopo), de forma a entender de forma inequívoca a origem da mudança e seus efeitos (MULCAHY, 2007). O “controle” em qualquer área de conhecimento nada mais é do que a correção de desvios, ou seja, sempre que o trabalho se distanciar daquilo que foi planejado anteriormente (linha de base ou baseline). Assim, sempre que necessário o trabalho é refeito ou redirecionado. Um sistema de controle de mudanças do escopo: • Define os procedimentos para efetuar mudanças no escopo do projeto e no escopo do produto. • Inclui a documentação, os sistemas de acompanhamento e os níveis de aprovação necessários para autorizar mudanças • Quando o projeto é gerenciado sob um contrato, o sistema de controle de mudanças também fica de acordo com todas as cláusulas contratuais relevantes; O sistema de controle de escopo depende também das seguintes documentações 1. Estrutura de decomposição de trabalho, que define o baseline do escopo do projeto 2. Relatórios de desempenho. Os relatórios de desempenho fornecem informações sobre o desempenho do escopo tais como quais produtos intermediários foram completados e quais não o foram. Relatórios de desempenho podem, também alertar a equipe do projeto para questões que podem causar problemas no futuro. 3. Requisições de mudança. As requisições de mudanças podem ocorrer de muitas maneiras – oral ou escrita, direta ou indireta, iniciada externa ou internamente, e legalmente imposta ou opcional. As mudanças podem exigir a expansão do escopo ou podem permitir que seja reduzido. A maioria das demandas de mudança é resultado de:
capítulo 2
• 77
• Um evento externo (por exemplo, uma mudança em uma regulamentação governamental). • Um erro ou omissão no detalhamento do escopo do produto (por exemplo, não incluir uma característica necessária no projeto de um sistema de telecomunicação). • Um erro ou omissão no detalhamento do escopo do projeto (por exemplo, usar uma lista de material (BOM) em vez de usar uma estrutura analítica do projeto (EAP). • Uma mudança no valor agregado (por exemplo, um projeto de recuperação ambiental é capaz de reduzir custos através do uso de uma tecnologia que não estava disponível quando o escopo do projeto foi originalmente definido). • Implementação de um plano de contingência, ou “workaround”, durante a ocorrência de um evento de risco. 4. Plano de gerência do escopo. Como resultados do sistema de controle de escopo podemos ter: I. Mudanças do escopo. Uma mudança do escopo é qualquer modificação no escopo combinado do projeto, conforme definido pela EAP aprovada. As mudanças do escopo do projeto, frequentemente, exigem ajustes no custo, no prazo, na qualidade ou em outros objetivos do projeto. Mudanças do escopo são retornos (feedback) ao longo do processo de planejar, os documentos técnicos e de planejamento são atualizados conforme necessidade, e as partes envolvidas são informadas conforme for apropriado. II. Ações corretivas. A ação corretiva é tudo aquilo que é feito para compatibilizar o desempenho futuro da programação com o plano do projeto. III. Lições aprendidas. As causas das variações, as razões por trás da ações corretivas tomadas, e outros tipos de lições aprendidas do controle de mudanças do escopo, devem ser documentadas para que estas informações se integrem a um banco de dados histórico tanto para o projeto em andamento quanto para outros projetos da organização. IV. Baseline ajustado. Dependendo da natureza da mudança, o baseline correspondente (prazo, custo, etc) pode ser revisado e re-emitido com o objetivo de refletir a alteração aprovada e criar um novo baseline para futuras mudanças.
78 •
capítulo 2
REFLEXÃO É importante você ter em mente que um projeto gera um produto/serviço, e que depois que esse produto/serviço é gerado, o projeto costuma findar (digo costuma, pois ainda pode haver alguma fase de acompanhamento do produto/serviço antes do término). Dessa forma, o ciclo de vida do projeto e o ciclo de vida de gerenciamento de projetos também terminam, continuando, agora, o ciclo de vida do produto, o qual poderá gerar vários outros projetos. A confusão com o jogo de palavras acima já não deve mais ser problema para você depois de tudo o que conversamos nesta unidade. Mas se ainda for, recomendamos que você volte ao início da unidade e a leia novamente. E ainda recomendamos que você envie mensagem ao professor e participe dos plantões para tirar suas dúvidas.
LEITURA Desta vez, não iremos recomendar a você a leitura de um determinado texto ou recomendar um determinado podcast. Vamos fazer um pouco diferente e um pouco mais divertido. Gostaríamos, na verdade, de recomendar que você assista a dois filmes de grandes sucessos, a saber: Onze homens e um segredo e Vida de inseto. Onze homens e um segredo é um filme de ação da Warner Bros. Estrelado por George Clooney e Brad Pitt, que fazem papel de ladrões profissionais que empreendem, na ocasião, u assalta a um casino em Las Vegas. O grande “barato” deste filme para nós, na disciplina de gerenciamento de projetos, é que o assalto ao casino na verdade é um projeto muito bem planejado e executado e vale a pena assistir com o olhar de um gerente de projetos. Já o filme Vida de inseto é uma animação dos estúdios Disney e mostra o empreendimento de uma pequena formiga contra grandes gafanhotos. Para nós, o filme é importante, pois mostra como erros de comunicação podem trazer grandes prejuízos ao projeto. Bom filme, pessoal!
ATIVIDADES Desenvolvemos, a seguir, um conjunto de perguntas para que você possa fixar o conteúdo aprendido neste capítulo. Responda às perguntas abaixo utilizando como base tudo aquilo que você estudou neste capítulo, nas conexões apresentadas e utilizando o conhecimento
capítulo 2
• 79
que você já possui de vivências profissionais ou de estudos de módulos passados referentes ao mundo coorporativo. 01. Os processos dos grupos de processos do ciclo de vida de gerenciamento de projetos mostrados pelo PMBOK também podem ser classificados em áreas de conhecimento. Quais são elas? 02. Qual é a importância da área de conhecimento de integração? 03. O que é gerenciamento do escopo e por que esse processo é importante? 04. O que pode incluir uma declaração de requisitos? 05. O que é uma EAP e como ela impacta no gerenciamento de projetos? 06. O que é um pacote de trabalho? 07. Quais são os aspectos positivos da definição de escopo? 08. O que são premissas de um projeto? Dê exemplos.
REFERÊNCIAS BIBLIOGRÁFICAS PRESSMAN, R. S. Engenharia de software. USA: McGrawHill, 2006. PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania: s.n., 2004. PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania: s.n., 2008. SOMMERVILLE, I. Engenharia de software. Rio de Janeiro: Addison Wesley, 2003. VARGAS, Ricardo.. Site do Ricardo Vargas. . Acesso em: Agosto 2015. VIEIRA, Marconi Fábio.. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro: Elsevier, 2007.
80 •
capítulo 2
3 Gerenciamento de Tempo, de Custo e Gerenciamento de Recursos Humanos
Normalmente, os processos de gerenciamento do tempo do projeto trabalham baseando-se nas saídas dos processos de escopo, portanto geralmente são executados após esses processos. Isso por que o gerenciamento do tempo é determinado com base nas atividades necessárias para a realização do projeto, que são baseadas nos pacotes de trabalho definidos na EAP na área de conhecimento de gerenciamento de escopo. Em projetos de TI, o gerenciamento de tempo também se configura como uma atividade complexa, uma vez que estimar/planejar tempo em atividades abstratas, como implantação ou desenvolvimento de software, não é algo tão trivial, muito embora a engenharia de software nos ofereça algumas técnicas, como vamos ver a seguir.
OBJETIVOS • Conceituar gerenciamento de tempo, de custo e de recursos humanos • Identificação das atividades de cada área • Sequenciamento de atividades • Estimativas de Duração • Ferramentas e técnicas de refinamento e acompanhamento para elaboração do cronograma
82 •
capítulo 3
3.1 Gerenciamento de Tempo A grande demanda de projetos torna o mercado mais competitivo e complexo, fazendo com que o gerenciamento de projetos seja uma ferramenta eficaz para as organizações. Dentro dessa ferramenta, um dos conceitos mais importantes é o Gerenciamento do Tempo, cuja função é controlá-lo eficientemente para atingir os objetivos planejados pela organização. O tempo está diretamente ligado a três fatores: escopo, custo e qualidade. Dessa forma, qualquer mudança em uma das variáveis citadas acima pode afetar as outras, i.e. qualquer atraso em seu tempo de um projeto poderá influenciar na mudança de escopo. Portanto, o gerenciamento do tempo, juntamente com o gerenciamento de custos, segundo Vargas (2009), são as mais visíveis áreas do gerenciamento de projeto. A grande maioria das pessoas que se interessam por projetos têm como objetivo inicial controlar prazos, confeccionar cronogramas e redes, etc. O principal objetivo dessa área é garantir que o projeto seja concluído dentro do prazo determinado. Como todos sabem, o tempo não espera! Especialmente por aquele gerente que constrói cronogramas baseados em datas impossíveis. O cronograma do projeto é sempre uma restrição, até mesmo quando a data de término não é crítica. Se um projeto atrasa, na maioria das vezes ele irá consumir um capital que ele não tinha provisionado, comprometendo, também, o seu custo, podendo até mesmo causar consequências ao produto, serviço ou qualquer que seja o resultado do projeto (VARGAS, 2009).
CURIOSIDADE Cerca de 68% dos projetos de Tecnologia da Informação (TI) são entregues com atraso, segundo o Standish Group. Na fase de Planejamento do Projeto são feitas as previsões, que são baseadas em premissas, como visto no capítulo anterior. Premissas, dentro do gerenciamento de projetos são hipóteses admitidas como certas, sem fundamentação, para fins de planejamento. Isso faz com que na prática o resultado não seja 100% exato. Assim, a experiência auxiliada por melhores práticas são fatores que melhoram a proximidade da estimativa com a realidade.
capítulo 3
• 83
Para Valeriano (1998), uma das áreas de conhecimento de projetos que deve ter uma administração mais rígida, é o tempo; sua gestão está diretamente ligada ao sincronismo das atividades envolvidas no projeto. Portanto, para que esse possa ser concluído no tempo previsto é necessário se fazer um minucioso controle e acompanhamento de todas essas atividades com a elaboração de um cronograma. Em suma, o gerenciamento do tempo em projetos inclui os processos necessários para realizar o término do projeto no prazo previsto, o que requer disciplina e controle eficientes, permitindo corrigir em tempo hábil os possíveis problemas com prazos, objetivando impedir sua gravidade no decorrer da execução. Standish Group A missão do Standish group é mudar o mundo dos projetos de software, voltado para a maneira de como esse projetos são gerenciados. A proposta de gestão de desenvolvimento de software resultará em um desenvolvimento de software mais rápido e mais seguro. A filosofia do grupo é baseada em reflexão de grupos, pesquisa intensiva e feedback constante.
Relatório CHAOS Há 16 anos, o Standish Group estuda projetos de TI. Ao longo desse tempo, a pesquisa CHAOS já estudou mais de 70 mil projetos de TI realizados. O CHAOS Report é frequentemente citado em artigos e apresentações sobre gerenciamento de projetos de TI. Essa pesquisa classifica o resultado de cada projeto de TI , de acordo com pesquisa realizada com gerentes de projeto, em uma destas três situações: Bem sucedido: O projeto é concluído dentro do prazo e orçamento planejados, com todos os recursos e resultados originalmente especificados. Deficitário: O projeto é concluído e operacionalizado, mas com atraso, acima do custo estimado ou com menos recursos e resultados que o especificado. Falho: O projeto é cancelado antes de ser concluído ou nunca é implementado.
84 •
capítulo 3
CONEXÃO Consulte também a comunidade brasileira do Standish Group Somos uma rede de informação que conecta profissionais que atuam na área de TI interessados no gerenciamento de projetos e no aprofundamento das questões práticas e teóricas a ele relacionadas. O propósito dessa rede é proporcionar informações e permitir o dialogo sobre as pesquisas e serviços oferecidos pelo The Standish Group. The Standish Group tem como missão apoiar você no desenvolvimento de conhecimentos e habilidades que aumentem suas chances de sucesso e proporcionem mais valor aos investimentos realizados http://brazil.standishgroup.com/index.php?r=site/page&view=about
No relatório CHAOS divulgado em 2014, janelas de tempo pouco realistas e expectativas irrealistas somam mais de 10% de fatores indicados como causas para falhas nos projetos de TI. FATORES QUE COMPROMETERAM OS PROJETOS % DE RESPOSTAS Falta de dados de entrada do usuário Requisitos e especificações incompletas Mudanças em requisitos e especificações Falta de apoio executivo Incompetência tecnológica Falta de recursos Expectativas irrealistas Objetivos pouco claros Janelas de tempo irrealistas Nova Tecnologia Outras
12,8% 12,3% 11,8% 7,5% 7,0% 6,4% 5,9% 5,3% 4,3% 3,7% 23%
Tabela 3.1 – Tabela relacionando a causa das falhas de projetos em TI, de acordo com relatório CHAOS, 2014. Tradução livre da autora.
CURIOSIDADE Mas por que há uma taxa tão baixa de projeto consegue ser finalizado dentro do prazo previsto? Atrasos na conclusão comprometem o custo, retardam a entrega e consequentemente, a disponibilidade de iniciar a utilização dos mesmos e/ou entrarem em operação. Atrasos podem causar também em quebras de cláusulas contratuais e consequente falha do projeto.
capítulo 3
• 85
Dessa forma, o gerenciamento do tempo se mostra um processo muito importante para que o projeto seja bem sucedido.
3.2 Processos do Gerenciamento do Tempo Os processos de gerenciamento do tempo do projeto trabalham baseando-se nas saídas dos processos de escopo, portanto geralmente são executados após esses processos. Devido ao fato de quer que o gerenciamento do tempo é determinado com base nas atividades necessárias para a realização do projeto, que são baseadas nos pacotes de trabalho definidos na EAP, definida quando da elaboração da declaração de escopo. Em projetos de TI, o gerenciamento de tempo se configura como uma atividade complexa, uma vez que estimar e ou planejar tempo em atividades abstratas, como implantação ou desenvolvimento de software, não é algo tão trivial, muito embora a engenharia de software nos ofereça algumas técnicas, como os pontos por função e os pontos por casos de uso. Contudo, apesar das técnicas, uma empresa madura deve ter uma grande base histórica de métricas para auxiliar no gerenciamento do tempo do projeto. O gerenciamento do tempo em projetos é composto dos processos descritos na figura 3.1. • Definição de atividades • Sequênciamento de atividades • Estimativa das durações das atividades • Desenvolvimento do cronograma • Controle do crongrama
Figura 3.1 – Processos de gerenciamento do tempo.
86 •
capítulo 3
Definição de Atividades O processo de definição de atividades envolve identificar e documentar as atividades específicas que devem ser realizadas para produzir os diversos níveis de subprodutos identificados na Estrutura de Analítica do Projeto (EAP). Esse processo deve englobar, portanto, a definição de atividades voltadas para o alcance dos objetivos do projeto. Além da EAP, a definição das atividades também depende da declaração do escopo, informações histórias, restrições e as premissas. A justificativa e os objetivos do projeto contidos na declaração do escopo devem ser considerados, explicitamente, durante a definição das atividades. As informações históricas (que atividades foram realmente requeridas em projetos anteriores semelhantes) devem ser consideradas na definição das atividades do projeto. Por último, as restrições são fatores que limitarão as opções da equipe de gerência do projeto; um exemplo disso é o desejo de usar o máximo da duração de uma atividade. Você se lembra do que é a EAP e a declaração de escopo? Em caso negativo, consulte a seção 2.3 do Capítulo 2.
Técnicas e Ferramentas para a Definição das Atividades A primeira ferramenta que trataremos neste capítulo é a Decomposição. Dentro do contexto do processo da Definição de Atividade a decomposição envolve subdividir os pacotes de trabalho do projeto em componentes menores e mais manejáveis para fornecer melhor controle do gerenciamento. A principal diferença entre a decomposição aqui descrita e a do Detalhamento do Escopo é que nesta as saídas são descritas como atividades (ações) em vez de subprodutos (itens tangíveis). A estrutura analítica do projeto e a lista de atividades são normalmente desenvolvidas sequencialmente, com a EAP começando as bases para o desenvolvimento da lista de atividades final. Em algumas áreas de aplicação, a EAP e a lista de atividades são desenvolvidas paralelamente. Outra ferramenta é a utilização de modelos. Uma lista de atividades, ou uma parte de uma lista de atividades de projetos anteriores, é frequentemente útil como modelo ou referência para um novo projeto. As atividades no modelo também podem conter uma lista dos perfis de recursos e suas respectivas horas de esforço, identificação dos riscos, produtos esperados e outras informações.
capítulo 3
• 87
Uma vez definidas as atividades, deve-se ter como resultados: • Lista de atividades. A lista de atividades deve incluir todas as atividades que serão realizadas no projeto. Deve ser organizada como uma extensão da EAP para assegurar que esta está completa e que não inclui qualquer atividade que não seja requerida como parte do escopo do projeto. Assim como na EAP, a lista de atividades deve incluir descrições de cada atividade para garantir que os membros da equipe do projeto entenderão como o trabalho será feito • Detalhamento do suporte. Os detalhes de suporte referentes à lista de atividades devem ser documentados e organizados de forma a facilitar seu uso por outros processos da gerência do projeto. Os detalhes de suporte devem sempre incluir a documentação de todas as premissas e restrições identificadas A quantidade de detalhes adicionais varia de acordo com a área de aplicação. • Atualizações na EAP. Ao utilizar a EAP para identificar quais atividades são necessárias, a equipe do projeto pode identificar a falta de algum subproduto ou pode ainda determinar que a descrição dos subprodutos precisa ser clareada ou corrigida. Qualquer uma destas atualizações deve ser refletida na EAP e na respectiva documentação, como por exemplo a estimativa dos custos. Estas atualizações são muitas vezes chamadas de refinamentos (refinements) e ocorrem mais frequentemente quando o projeto envolve uma tecnologia nova ou em desenvolvimento.
Sequenciamento de Atividades Ao final do processo de definição de atividade, tem-se uma lista contendo todas as atividades planejadas que precisam ser executadas para a finalização do projeto. Porém, essas atividades não estão cronologicamente organizadas, ou seja, não há ainda nenhuma informação que diga qual atividade vem antes ou depois. Dessa forma, há a necessidade de se realizar o sequenciamento lógico das atividades identificadas, sendo esse trabalho de responsabilidade deste processo. Deve-se, primeiramente, definir qual o modelo de diagrama a ser utilizado para fazer o sequenciamento das atividades. Independente do método escolhido, é necessário determinar também o tipo de dependência entre as atividades, que são dependência obrigatória, arbitrária e externa. As dependências obrigatórias não podem ser mudadas, pois dependem da natureza do trabalho. Exemplo: não se pode pintar uma parede sem rebocá-la
88 •
capítulo 3
primeiramente. Já as dependências arbitrárias são baseadas em melhores práticas de mercado Exemplo: Devemos pintar a parede primeiramente e depois instalar os carpetes, pois isso é o recomendável, uma vez que por qualquer descuido poderíamos sujar os carpetes. Por sua vez, a dependência externa depende de atividades fora do domínio e controle do projeto. Exemplo: Contratação de quaisquer serviços de terceiros que esteja relacionado a uma atividade do seu projeto. Uma dependência externa pode vir a provocar atrasos e problemas de qualidade no projeto se, por exemplo, o fornecedor não for confiável e qualificado.
Estimar as durações das atividades Uma vez definidos o planejamento de todas as atividades que deverão ser executadas para o término do projeto e realizado o respectivo sequenciamento, os recursos necessários para a execução das atividades estão prontos. O próximo passo é planejar (estimar) a duração que cada atividade terá e depois colocar as atividades dentro do calendário dos recursos montando, dessa forma, o cronograma do projeto. Estimar tempo em atividades planejadas é algo complexo em qualquer área, mas na área de TI esta atividade é um pouco mais complicada pela característica abstrata das tarefas e seu cunho intelectual, em alguns casos quase “artísticos” (por exemplo o desenvolvimento de um software científico como processamento de imagem ou biotecnologia). Por isso, é comum esse processo de estimativa de tempo das atividades seja realizado por pessoas que estão mais acostumadas com o contexto e natureza do projeto (e que utilizam a experiência delas para realizar estimativas mais confiáveis) e também é realizado em caráter progressivo, à medida que as informações necessárias para as estimativas vão ficando cada vez mais claras. Mas, não só a “arte” e a experiência ou conhecimento tácito dos colaboradores são alternativas para este processo. Há técnicas sistematizadas como pontos por função e pontos de caso de uso que podem ser utilizadas juntamente com bases históricas para a determinação de estimativas de tamanho de software. Para se realizar um planejamento das estimativas do projeto, deve-se: examinar e consolidar bem o escopo antes de estimar os prazos do projeto; ser realista com a equipe quanto aos prazos; verificar lições aprendidas de projetos
capítulo 3
• 89
anteriores; envolver a equipe do projeto e também os clientes, se possível e considerar riscos e planejar ações. Para executar a estimativa das durações das atividades é necessário ter disponíveis a lista de atividades, atributos das atividades, requisitos de ,recursos das atividades, calendário do recurso e a declaração do Escopo do Projeto, fatores ambientais da empresa.
Técnicas e Ferramentas para sequenciamento de atividades Uma das ferramentas utilizadas é a opinião de pessoas especializadas nas tarefas definidas. Outras técnicas passíveis de utilização são a estimativa análoga, que admite que seja utilizada a duração real de atividades em projetos passados como base para a estimativa de atividades parecidas no projeto atual. Por isso, a base histórica de projetos e a opinião especializada são entradas importantes para essa técnica. Já a estimativa paramétrica utiliza os valores unitários de produtividade por hora de trabalho (por exemplo, para se colocar o piso em uma casa demora-se em média 10m2/dia) e os multiplica pela quantidade total do trabalho (então, se temos 10m2 de piso para colocar em uma determinada atividade, estima-se que a atividade terá a duração de 10 dias); A estimativa de três pontos considera três cenários para estimar o prazo. As questões a serem feitas são: • Baseando-se em um cenário otimista (tudo dará certo), qual é o prazo esperado? Prazo otimista (Po) • Baseando-se em um cenário pessimista (tudo dará errado), qual é o prazo esperado? Prazo pessimista (Pp) • Baseando-se em um cenário mais provável, qual é o prazo esperado? Prazo mais provável (Pmp) Prazo esperado =
Po + 4Pmp + Pp 6
Como dito anteriormente, o processo de estimativa é algo complexo. Por isso, é comum a adição de reservas de tempo (ou buffers ou ainda reservas para contingência) às estimativas para contingenciar o risco das incertezas do cronograma. Essa técnica é chamada de análise de reservas.
90 •
capítulo 3
A quantidade desta reserva pode ser um número fixo por tarefa, uma porcentagem por tarefa ou ainda pode ser adquirido por meio de uma análise utilizando métodos quantitativos. O processo de estimativa das durações da atividades resulta em: estimativa de duração das atividades e atualização dos documentos do projeto.
Desenvolvimento do cronograma O desenvolvimento do cronograma objetiva atribuir datas (prazos) de início de término para as atividades. Se tais datas não forem realistas, é improvável que o projeto termine conforme planejado. O processo de desenvolvimento do cronograma deve, frequentemente, ser repetido antes da determinação do cronograma do projeto. Este processo é útil para definir quando cada atividade do projeto se inicia e termina. Para desenvolvimento do cronograma, é necessário ter disponíveis: lista de atividades, diagrama de Rede do Cronograma do Projeto, calendários de disponibilidade de recursos, estimativa de duração das atividades; declaração do Escopo do Projeto e fatores Ambientais da Empresa.
Ferramentas e técnicas para desenvolvimento do cronograma • Gráfico de Gantt • Método do caminho crítico – por meio dessa técnica é possível descobrir em um gráfico de redes qual é o caminho de atividades mais longo que será feito no projeto e aquele que terminará mais cedo. Com essa análise é possível gerenciar o tempo de entrega do projeto aplicando então técnicas de paralelismo e compressão às atividades do caminho mais longo, ou seja, o caminho crítico do projeto! • Aplicação de antecipações e esperas – durante o sequenciamento das tarefas antecipações e atrasos podem ocorrer e nesta técnica eles são ajustados. • Compressão do cronograma – técnicas para a redução do cronograma sem reduzir o escopo do projeto: são analisadas as compensações entre custo e cronograma em busca da redução do tempo de execução de uma dada atividade. • Paralelismo – descobrir no grafo de rede de atividades as atividades que estão seriadas e tentar a execução das mesmas em paralelo para reduzir o tempo do caminho crítico.
capítulo 3
• 91
• Gráfico de Milestones • Baseline Nesta disciplina, discutiremos com maior profundidade o Gráfico de Gantt, o método do caminho crítico (CPM ou Critical Path Method), gráfico de Milestones e a Baseline.
Gráfico de Gantt O diagrama ou gráfico de Gantt é um gráfico usado para ilustrar o avanço das diferentes etapas de um projeto. Os intervalos de tempo representando o início e fim de cada fase aparecem como barras coloridas sobre o eixo horizontal do gráfico. É possível utilizar essa ferramenta para determinar o início e o fim das atividades individuais de um projeto. Os passos para elaboração são: decompor o projeto em atividades discretas, determinar a sequência destas atividades e ter uma estimativa de tempo para cada atividade (suposta como determinística) e conhecida. Veja um exemplo de gráfico de Gantt na figura 3.2. Atividade
Duração 5
10
15
20
25
A B C Gráfico de Gantt
planejado realizado
Figura 3.2 – Exemplo de um gráfico de Gantt.
A utilização do gráfico de Gantt tem vantagens e desvantagens, representadas na figura a seguir.
92 •
capítulo 3
Vantagens - Visual/ Fácil construção - Entendimento continuado - Força um planejamento Desvantagens - Não são adequados para projetos complexos de grande escala - Não mostram claramente a interdependência de atividades - Não fornece indicador de prioridade quando existem atividades que concorrem por recursos Figura 3.3 – Vantagens e Desvantagens da utilização do gráfico de Gantt.
Método do caminho crítico (Critical Path Method – CPM) Técnica usada para planejar e controlar as atividades necessárias para a execução de um projeto. Mostrando cada uma dessas atividades e o tempo associado, é possível determinar o caminho crítico, identificando os elementos que restringem o tempo total de projeto. Utiliza-se quando tiver que gerenciar projetos complexos e de longa duração. Mostrando cada uma dessas atividades e o tempo associado, é possível determinar o caminho crítico, identificando os elementos que restringem o tempo total de projeto. Para utilização do método do caminho crítico é necessário identificar as atividades e montar o diagrama de rede do projeto, representado num grafo. Uma atividade do Projeto é qualquer parte (discreta) deste que consome Tempo, Recursos (capital, pessoal, materiais) ou ambos, para ser efetuada. No CPM a duração das atividades é Determinística (variância nula). Grafo é onde as atividades do projeto são colocadas de acordo com relações de precedência Primeiramente, vamos tratar da construção do diagrama de rede do projeto.
Método do diagrama de flecha (ADM - Arow Diagramming Method ou Diagrama Activity on Arc - AOA). Este é um método de construção de diagrama de rede que utiliza setas para representar as atividades e as conecta por meio de nós que representam as dependên-
capítulo 3
• 93
cias um diagrama simples de rede lógica utilizando o ADM. Esta técnica é também chama de atividade no arco (AOA - Activity-on-arc) . O ADM utiliza apenas relações de dependência do tipo fim/início e pode requerer o uso de atividades fantasmas (também chamadas de fictícias ou dummy) para definir corretamente o relacionamento lógico. O ADM pode ser feito manualmente ou no computador. No Diagrama de Rede, cada atividade possui um início e um fim, que são pontos no tempo. Esses pontos no tempo são conhecidos como eventos. As atividades são representadas por setas e os eventos — ponto inicial e final — por círculos (chamados também de nós). A seta aponta para o círculo que representa o evento final, para dar a idéia de progressão no tempo. As atividades são representadas por números ou letras e os círculos são numerados, em ordem crescente, da esquerda para a direita. A
10
50
E
D G
1
B
30
C
F 40
70 H
I
20
J
60
K
Figura 3.4 – Exemplo de um Diagrama de rede AOA.
Uma vez construído o diagrama de rede, é necessário determinar: Tempo mais cedo de uma etapa: é o momento mais cedo em que ocorre a conclusão de todas as atividades de que a etapa é Etapa Final ou é o momento mais cedo em que pode ocorrer o início de qualquer das atividades de que a etapa é Etapa Inicial. Utilizaremos a notação TE – time early. Para calcular o tempo mais cedo de uma etapa j: • Iniciar o cálculo na etapa inicial do projeto com TE = 0; • Percorrer, no sentido direto, todos os arcos que de uma ou mais etapas conduzem à etapa “j”; • Para cada um daqueles arcos, somar o TE da etapa-origem do arco com a duração da atividade associada ao arco; • O TE da etapa “j” é igual à maior das somas calculadas.
94 •
capítulo 3
Tempo mais tarde de uma etapa: é o momento mais tarde em que ocorre a conclusão de todas as atividades de que a etapa é Etapa Final ou é o momento mais tarde em que pode ocorrer o início de qualquer das atividades de que a etapa é Etapa Inicial. Utilizaremos a notação TL – time later. Para calcular o tempo mais tarde de uma etapa “j”: • Iniciar o cálculo partindo do Tempo Mais Tarde da etapa final do projeto; • Percorrer, no sentido inverso, todos os arcos com extremo final em uma ou mais etapas e extremo inicial na etapa “j”; • Para cada um daqueles arcos, subtrair ao TL da etapa de chegada do arco a duração da atividade associada ao arco; • O TL da etapa “j” é igual à menor das diferenças calculadas. Folga de uma etapa: é o intervalo de tempo em que ocorre a conclusão de todas as atividades de que a etapa é Etapa Final. A Folga da Etapa é igual a TL-TE. Veja na figura 3.5 a representação gráfica dos elementos acima descritos. Abreviatura utilizada neste livro: F; A Folga da Etapa 10 é F10 = TL10 -TE10 = 17 – 12 = 5 unidades de tempo
TE
TL 1
10
12
17 10
Figura 3.5 – Representação gráfica de TE, TL e F.
Um exemplo muito simples de um Diagrama de Rede é o planejamento de um jantar. A decisão de oferecer o jantar pode ser considerada a primeira atividade no projeto "oferecer um jantar". O ofertante, tendo decidido positivamente pelo jantar, irá agora comprar os ingredientes e fazer uma lista cuidadosa dos convidados. Essas duas atividades podem ocorrer ao mesmo tempo, embora ambas só possam ter início após a decisão de oferecer o jantar. Uma vez elaborada a lista de convidados, é possível enviar os convites. Por outro lado, uma vez comprados os ingredientes, é possível preparar o jantar. Uma vez preparado o jantar, pode-se deixar a casa em ordem para a recepção. Segue-se a recepção aos convidados, que deve obrigatoriamente ocorrer após a emissão dos convites e após se deixar a casa em ordem. Finalmente, recepcionados os convidados, pode-se servir o jantar, e dar por encerrado o "projeto".
capítulo 3
• 95
A tabela 3.2 mostra as atividades descritas e a figura 3.5 ilustra o diagrama de rede AOA correspondente: ATIVIDADES
ATIVIDADES PRECEDENTES IMEDIATAS
DESIGNAÇÃO
Decidir oferecer o jantar Comprar ingredientes Fazer lista de convidados Fazer o jantar Expedir os convites Colocar casa em ordem Recepcionar convidados Servir o janta
A B C D E F G H
Nenhuma A A B C D E.F G
Tabela 3.2 – Representação das atividades referentes ao planejamento de um jantar.
3
D
5
B
1
A
F
2 C
4
6
G
7
H
8
Figura 3.6 – Diagrama de rede AOA representando as atividades de planejar um jantar.
Num Diagrama de Rede, denomina-se caminho a qualquer sequência de atividades, que siga desde o nó inicial até o nó final. Na figura 3.5, por exemplo, distinguimos dois caminhos, contendo as seguintes atividades: Caminho 1: A B D F G H Caminho 2: A C E G H Chama-se de duração de um caminho à soma das durações de todas as atividades que o compõem. Em um Diagrama de Rede, o caminho com a maior duração é chamado de caminho crítico e governa o tempo de término do projeto: o tempo de término de um projeto é igual à duração de seu caminho crítico. Qualquer atraso neste caminho, automaticamente determinará um atraso no projeto. As atividades do caminho crítico são chamadas de atividades críticas. Nenhuma dessas
96 •
capítulo 3
atividades pode se atrasar, sem que o projeto também se atrase. Numa linguagem típica, dizemos que essas atividades não têm folga ou, equivalentemente, que sua folga é zero. Em outros caminhos que não o caminho crítico, as atividades podem sofrer algum atraso sem que implicar em atraso do projeto.
EXERCÍCIO RESOLVIDO 01. Dado o Diagrama de Rede abaixo, determine: a) os caminhos possíveis e a duração de cada um; b) o caminho crítico e a duração esperada do projeto; c) a folga de cada caminho, ou seja, o tempo total que as atividades do caminho podem se atrasar sem interferir na duração do projeto. 6 C 2 A 1
4
se
4s
s
ana
em 8s
ana
s
as
6 3
se
a em
H
ma
na
s
G
4
7
10 semanas
s
na
E
an
10
D
em
B
m
s
ana
em
6s
I
s
F 12 semanas
s
na
ma
e 5s 5
Solução: a) Caminhos e sua duração Note que existem apenas quatro caminhos, cujas durações são dadas pela soma das durações das atividades que os constituem:
CAMINHO A–C–H A–D–G B–E–G B–F–I
DURAÇÃO 24 semanas 22 semanas 20 semanas 21 semanas
capítulo 3
• 97
b) Caminho, crítico e duração esperada do projeto O caminho crítico é o de maior duração, portanto: A —— C ——— H com 24 semanas, que é a duração esperada do projeto. c) Folga de cada caminho A folga de cada caminho é a diferença entre a duração do caminho crítico e a do próprio caminho;
CAMINHO A–C–H A–D–G B–E–G B–F–I
DURAÇÃO 24 – 24 = 0 24 – 22 = 2 semanas 24 – 20 = 4 semanas 24 – 21 = 3 semanas
Convenções para a Construção de Diagramas de Rede O processo de construção do Diagrama de Rede para um projeto envolve, preliminarmente, a especificação de todas as atividades que compõem o projeto. Esta é uma etapa chave, que dá base à construção do Diagrama propriamente dito. Na construção do Diagrama de Rede, cada atividade será representada por uma seta, que se inicia e termina cm um nó. Existem diversas regras básicas para se indicar as relações entre as atividades. Para que o seja possível realizar os cálculos de TE, TL e F, é também necessário que sejam especificadas as durações das atividades. Vejamos agora as convenções fundamentais para a construção de um Diagrama de Rede: 1a. Cada atividade é representada por uma única seta, cujo comprimento não precisa guardar relação com a duração da atividade. 2a. A direção da seta indica as progressões no tempo. 3a. Se uma atividade começa num evento (nó), ela só pode se iniciar depois que todas as atividades terminando naquele evento tenham sido completadas. 4a. As atividades são identificadas, principalmente por programas de computador, por seus nós inicial e final, devidamente numerados da esquerda para a direita. Desta forma, é impróprio que duas atividades tenham os mesmos nós inicial e final.
98 •
capítulo 3
A representação abaixo da figura 3.7, que está incorreta para efeitos práticos, mostra que a atividade C só pode começar depois que tanto A quanto B tenham sido concluídas. A representação é inconveniente, pois A e B têm os mesmos nós inicial e final. A 1
2 B
Figura 3.7 – Exemplo de representação AOA incorreta.
Corrige-se tal situação criando uma atividade fantasma, com duração zero e sem influência real no Diagrama de Rede. A atividade fantasma serve apenas para auxiliar na individualização das atividades. Veja na figura 3.8 como a criação da atividade fantasma. C resolve o problema: 1
A
2
B
C
4
3
Figura 3.8 – Rede AOA correta.
Note-se que C depende diretamente de A e de B, que por sua vez não pode se iniciar antes que B esteja concluída. Logo, indiretamente, fica estabelecida a relação de dependência entre C e B. Dessa forma, a importância de se identificar o caminho crítico fundamentase nos seguintes parâmetros: permitir saber, de imediato, se será possível ou não cumprir o prazo anteriormente estabelecido para a conclusão do plano e identificar as atividades críticas que não podem sofrer atrasos, permitindo um controle mais eficaz das tarefas prioritárias. Ainda, o método CPM permite priorizar as atividades cuja redução terá menor impacto na antecipação da data final de término dos trabalhos, no caso de ser necessária uma redução desta data final. Possibilita o estabelecimento da primeira data do término da atividade e o estabelecimento da última data do término da atividade.
capítulo 3
• 99
Gráfico de Milestones O gráfico de milestones é uma ferramenta que permite o controle gerencial ao longo do projeto através da definição de pontos de checagem ou marcos de desenvolvimento e é utilizado em conjunto e baseado no gráfico de Gantt. Considera apenas eventos significativos de um projeto, chamados de eventos cujas atividades tem duração zero e alocação de recurso zero.
Evento
Jan
Fev
Data Atual Mar Abr
Mai
Jun
Jul
Ago
Subcontratos Assinados Especificações Finalizadas Projeto Revisto Subsistema Testado Primeira Unidade Entregue Plano de Produção Completado Planejado
Realizado
Figura 3.9 – Exemplo de gráfico de milestones.
Marcos ou eventos são acontecimentos significativos no desenvolvimento do projeto e que servem de parâmetros para o controle gerencial, tais como: 1. Assinatura de contrato 2. Início de uma atividade 3. Conclusão de u ma etapa 4. Teste nos subprodutos ou no produto final.
Baseline A linha de base do cronograma ou baseline é como uma fotografia retirada no momento da aprovação do que foi planejado, similar a um congelamento do cronograma planejado. É usada para avaliar a evolução do projeto monitorando o prazo através da comparação do planejado com o realizado. O gerente de projeto deve entender as causas das alterações do cronograma e influenciá-las sempre que possível. A linha de base do cronograma também ajuda o GP a negociar as mudanças solicitadas demonstrando o impacto que ocorrerá no prazo do projeto.
100 •
capítulo 3
Controle do cronograma O controle do cronograma é uma função contínua e essencial na gestão do projeto durante toda sua trajetória. Isso possibilitará identificar-se a necessidade de tomadas de ações corretivas, quando forem verificados desvios negativos ou tendências dos mesmos virem a ocorrer, em relação ao que foi planejado.
Sistema de controle de mudanças do cronograma O sistema de controle de mudanças do cronograma define os procedimentos pelos quais o cronograma do projeto pode ser mudado. Isto inclui manuais, sistemas de acompanhamento, e níveis de aprovação para que as mudanças necessárias sejam autorizadas. O controle de mudanças do cronograma deve estar integrado com o sistema integrado de controle de mudança. Ferramentas para realizar o controle do cronograma de um projeto incluem: Medição do desempenho. As técnicas de medição de desempenho ajudam a determinar a magnitude de quaisquer variações que ocorram. Uma parte importante do controle de mudanças no cronograma é decidir se a variação do cronograma exige uma ação corretiva. Por exemplo: um grande atraso em uma atividade que não é crítica pode ter um efeito pequeno no projeto total, enquanto pequenos atrasos em atividades críticas ou “quase” críticas podem requerer ações imediatas. Planejamento adicional. Poucos projetos se desenvolvem exatamente de acordo com o plano. As mudanças em perspectiva podem requerer novas ou revisadas estimativas de duração das atividades, modificações na seqüência das atividades ou análise de cronogramas alternativos. Softwares de gerência de projeto. Os softwares de gerência de projeto estão descritos A capacidade dos softwares de gerência de projetos para acompanhar as datas planejadas versus as datas reais e prever os efeitos de mudanças no cronograma, reais ou potenciais torna-os uma ferramenta útil para o controle do cronograma. Análise de variação. A execução do processo da análise de variação durante a monitoração do cronograma é o elemento chave para o controle do tempo. A comparação das datas alvos com as realizadas de início e fim, nos fornece informações úteis para a detecção de desvios e para a implementação de ações corretivas em caso de atraso. As etapas comuns são:
capítulo 3
• 101
1. Verificar qualidade das informações coletadas; 2. Determinar variações entre real x linha de base; 3. Usar equações específicas para quantificar as variações; 4. Determinar impacto das variações nos custos e no cronograma; 5. Analisar tendências das variações e documentar quaisquer descobertas sobre fontes de variação e área de impacto.
3.3 O Gerenciamento de Custo O gerenciamento de custos tem como objetivo garantir que o capital disponível será suficiente para obter todos os recursos para se realizar os trabalhos do projeto. Portanto, o gerenciamento de custos não pode considerar apenas os cursos incorridos no próprio projeto. Muitas vezes, o projeto está desenvolvendo um produto, ou serviço, com interesse comercial, e, esse produto, segundo Vargas (2009), por sua vez, estará recompensando financeiramente a empresa, retornando tanto o dinheiro investido quanto o lucro desejado, estabelecido na concepção do projeto. Fim das receitas ou Morte do Produto
Lucro final do empreendimento
$w
Rec
per aci
eita
ona l
Ope
rac
ion al
$x
Luc ro O
Início da Comercialização
y meses
z meses Breakeven (tempo de retorno)= z meses
eto
roj oP
n to
en
im est Inv
Investimento acumulado
Retorno acumulado
$k
t meses Fim da Vida Comercial do Produto
Investimento Total no Projeto $x
$x
Figura 3.10 – Ciclo financeiro de vida de um projeto Fonte: Vargas (2009).
102 •
capítulo 3
Tempo
Na figura anterior, tem-se em um primeiro momento, o ciclo de investimentos no projeto. O custo total do projeto é de $x e seu prazo de desenvolvimento é de y meses. Após esse período, inicia-se, imediatamente, a comercialização, obtendo uma receita conforme a curva superior do gráfico e um lucro operacional dado pela segunda curva dos retornos acumulados. Quando o lucro operacional acumulado atinge $x, tem-se o Breakeven1 do projeto, ou seja, o tempo que o projeto leva para se pagar, que é dado por z meses a partir do início do projeto, ou z-y meses a partir do início da comercialização do produto (VARGAS, 2009). Após esse período, o projeto passa a ter um lucro real, determinado pelo valor do lucro operacional que superar $x. Porém o produto desenvolvido também tem um ciclo de vida comercial e após um tempo t, o produto se deteriora comercialmente, tendo alcançado uma receita operacional final de $k, um lucro operacional total de $w e um lucro final do empreendimento (resultado) de $(w-x) (VARGAS, 2009). Outro aspecto importante com relação ao gerenciamento de custos diz respeito aos orçamentos. O orçamento não pode ser considerado simplesmente como uma visão do plano. Ele é um mecanismo poderoso de controle. O orçamento serve como parâmetro de comparação, uma linha de base da qual se extraem informações sobre o desempenho financeiro do projeto. O orçamento precisa ser validado ao longo do tempo, durante a execução do projeto (controle de custos), para que os eventuais problemas sejam identificados o mais cedo possível par que a solução possa ser antecipada, evitando-se assim, danos mais graves ao orçamento (VARGAS, 2009). Muitas vezes, o gerenciamento de custos propicia um processo de recompensa para os envolvidos no projeto, através de participação nos seus resultados. Nesses casos, o controle de custos merece uma atenção especial, sendo talvez alvo de um processo de orçamento paralelo, de modo a garantir que eles reflitam o real resultado do projeto. As maiores causas de falhas no gerenciamento de custos podem ser atribuídas a elementos externos ao processo isolado de custos, como por exemplo: • interpretação errada do trabalho a ser realizado; • omissão na definição do escopo do trabalho; • cronograma pobremente definido ou excessivamente otimista; • fracasso na avaliação de riscos; • estrutura analítica do projeto (WBS) mal definida; • parâmetros de qualidade mal estabelecidos; • fracasso na estimativa dos custos indiretos e administrativos do projeto. 1 Break Even do projeto:
capítulo 3
• 103
3.3.1 Processos de Gerenciamento de Custos O gerenciamento do custo do projeto inclui os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos de modo que seja possível terminar o projeto dentro do orçamento aprovado. (PMI, 2012). Segundo o PMBOK (2008), o gerenciamento de custos é responsável por gerenciar os custos dos recursos que são necessários para finalizar todas as atividades planejadas no gerenciamento de escopo e tempo. Do que foi dito acima, podemos concluir que o gerenciamento de custo está fortemente ligado a um bom gerenciamento de escopo e tempo. Para realizar o gerenciamento de custo de projetos, o PMBOK (2008) traz 3 processos, sendo 2 de planejamento e 1 de monitoramento e controle, a saber: 1. Estimar os custos; 2. Determinar o orçamento; 3. Controlar os custos. 3.3.1.1 Estimar os custos Este processo faz parte do grupo de processos de planejamento. A estimativa dos custos da atividade do cronograma envolve o desenvolvimento de uma aproximação dos custos dos recursos necessários para terminar cada atividade do cronograma. (PMBOK, 2004). Neste processo é que cada atividade do cronograma recebe uma estimativa do custo necessário para a sua execução. Assim como outras estimativas, a precisão da estimativa de custo aumenta conforme as informações disponíveis vão aumentando, sendo que nas fases iniciais de planejamento do projeto uma possível faixa de erro seria de –50% a 100% , e em fases posteriores essa faixa reduzir-se-ia para –10% a +15%. 3.3.1.2 Determinar o orçamento Este processo faz parte do grupo de processos de planejamento A orçamentação envolve a agregação dos custos estimados de atividades do cronograma individuais ou pacote de trabalhos para estabelecer uma linha base dos custos totais para a mediação de desempenho do projeto. (PMBOK, 2004 e 2008).
104 •
capítulo 3
Basicamente, a orçamentação é a soma dos custos das atividades individuais, já incluindo as reservas de contingências para formar a linha base de custo do projeto. Ainda, a orçamentação pode incluir as reservas de gerenciamento, que estão fora da linha base do projeto e servem para contingenciar eventos “desconhecidos, desconhecidos”. 3.3.1.3 Controlar os Custos Este processo faz parte do grupo de processos de monitoramento e controle. O controle de custos do projeto procura as causas das variações positivas e negativas e faz parte do controle integrado de mudanças. (PMBOK, 2004 e 2008). Esse processo tem como responsabilidade gerenciar todas as mudanças que acontecem no baseline de custo do projeto, bem como gerenciar os fatores que podem criar mudanças neste baseline. As técnicas utilizadas para o controle de custos são bem avançadas e dignas de um curso extra só para elas. No contexto desta disciplina, vamos apenas citá-las.
3.3.2 Fatores Importantes No gerenciamento de custos, é importante que se atente para os seguintes fatores: • em projetos sob contrato, é importante diferenciar estimativas de custos de precificação: custos são resultantes das necessidades de recursos, etc., do projeto, enquanto o preço é uma decisão de estratégia de negócio da organização; • qualquer estimativa de custos deve vir acompanhada por sua memória de cálculo; • bancos de dados comerciais sempre podem ser utilizados na estimativa de recursos e custos, bem como os registros obtidos em projetos anteriores; • muitas empresas patrocinam seus projetos, mesmo com os custos não sendo recuperados, porque têm interesse em atingir uma meta de longo prazo para a organização.
capítulo 3
• 105
3.3.3 Plano de Gerenciamento de Custos O Plano de Gerenciamento de Custos é auxiliar ao plano de projeto que descreve os procedimentos que serão utilizados para gerenciar todos os custos do projeto. No plano, segundo Vargas (2009), deve estar documentado: • título do projeto; • nome da pessoa que elaborou o documento; • descritivo dos processos de gerenciamento de custos (regras gerais); • descrição das reservas gerenciais e da autonomia em sua utilização; • sistema de controle de mudanças de prazos (Time Change Control System); • frequência de avaliação do orçamento do projeto e das reservas gerenciais; • alocação financeira das mudanças no orçamento; • nome do responsável pelo plano; • frequência de atualização do plano de gerenciamento de custos; • outros assuntos relacionados ao gerenciamento de custos não previstos no plano; • registro de alterações no documento; • aprovações.
CONEXÃO Conexão: Há um outro podcast do Ricardo Vargas chamado “Importância da Estrutura Analítica (EAP) no Gerenciamento de Custos do Projeto” e disponível em http://www.ricardovargas.com/pt/podcasts/wbs_costmgmt/, que fala um pouco sobre a importância da EAP na orçamentação do projeto. É uma conexão interessante a partir do momento que Ricardo Vargas chama a atenção para a interligação de dois processos do PMBOK.
3.4 O Gerenciamento de Recursos Humanos O gerenciamento dos recursos humanos do projeto inclui os processos que organizam e gerenciam a equipe do projeto que é composta por pessoas com funções e responsabilidades atribuídas e que contribuirão para o término do projeto. (PMBOK, 2004 e 2008). Assim, o gerenciamento dos recursos humanos tem como objetivo central fazer o melhor uso dos indivíduos envolvidos no projeto. Como se sabe, as pessoas
106 •
capítulo 3
são o elo central dos projetos e seu recurso mais importante. Eles definem as metas, os planos, organizam o trabalho, produzem os resultados, direcionam, coordenam e controlam as atividades do projeto, utilizando suas habilidades técnicas e sociais. Todos os resultados do projeto podem ser vistos como fruto das relações humanas e das habilidades interpessoais dos envolvidos, uma vez que a satisfação pessoal e a qualidade de vida estão se tornando um dos fatores-chave da motivação de qualquer profissional (VARGAS, 2009). No passado, a maioria dos projetos se preocupou unicamente com aspectos técnicos, que foram altamente desenvolvidos. Porém, os aspectos humanos, que poderiam conduzir o projeto aos mesmos ganhos do desenvolvimento técnico, foram relegados a um segundo plano. Agora, são eles o foco dos principais estudos e trabalhos na área, de modo a compensar essa desproporcionalidade. O sucesso ou o fracasso do projeto dependem diretamente do gerenciamento dos recursos humanos. Isso porque são as pessoas que podem mudar os rumos de um projeto, levando-o ao sucesso ou ao fracasso, dependendo de seu grau de envolvimento, motivação e engajamento com a equipe. Como os custos e o fluxo de caixa variam significativamente através do ciclo de vida do projeto, os recursos humanos são necessários em vários níveis de especialidade e experiência, dependendo da natureza do trabalho a ser realizado, do nível de maturidade do time do projeto e das restrições internas e externas. Quanto ao conceito de equipe, segundo o PMBOK (2008), um projeto é composto basicamente por dois tipos de equipes: a equipe do projeto, que é responsável pela execução do projeto; e a equipe de gerenciamento de projeto (que também pode ser chamada de equipe principal, executiva ou líder), que é responsável pelo ciclo de vida de gerenciamento de projeto planejando-o e controlando-o. Normalmente, essa separação de equipes é vista em grandes projetos, nos quais os papéis são muito bem definidos e quase sempre vivenciados por indivíduos diferentes. Já nos pequenos projetos e em pequenas empresas, os vários papéis dessas duas equipes podem ser executados pelas mesmas pessoas. Nesta área de conhecimento, o gerente de projetos deverá: • definir a hierarquia de comando do projeto; • criar um plano de gerenciamento das equipes dizendo como os RH serão contratados, desenvolvidos, motivados e outros; • realizar a contratação e mobilização do RH; • executar os treinamentos e desenvolvimentos dos RH; e • acompanhamento de todos os RH do projeto.
capítulo 3
• 107
Essas atividades são realizadas por meio de 4 processos, que perfazem o ciclo de planejamento, de execução e de monitoramento e controle, a saber: 1. Desenvolver o plano de recursos humanos. 2. Mobilizar a equipe do projeto; 3. Desenvolver a equipe do projeto. 4. Gerenciar a equipe do projeto.
3.4.1 O desenvolver o plano de recursos humanos Este processo faz parte do grupo de processos de planejamento. O planejamento de recursos humanos determina funções, responsabilidades e relações hierárquicas e cria o plano de gerenciamento de pessoal. (PMI, 2012). Neste processo é que será realizado o plano de recursos humanos, que é um planejamento consolidado em um documento que mostra toda a hierarquia de pessoas do projeto e ainda traz informações sobre contratação e mobilização dos membros da equipe do projeto, critérios para o desligamento dessas pessoas do projeto, planos de treinamento, motivação e segurança.
3.4.2 Mobilizar a equipe do projeto Este processo faz parte do grupo de processos de execução. É o processo de confirmação da disponibilidade e obtenção dos recursos humanos necessários para terminar o projeto, sendo que a equipe de gerenciamento de projeto pode ter, ou não, controle sobre essas seleções. (PMBOK, 2012). Este processo é responsável por contratar, se necessário, e mobilizar os recursos humanos necessários para a execução das atividades que irão compor o trabalho do projeto (VARGAS, 2009). É bom lembrar que o gerente de projetos pode (ou não) ter controle sobre o processo de contratação dessas pessoas. Ou seja, nem sempre o gerente de projetos é responsável pela seleção dos membros da equipe. Isso por que as organizações que estão executando o projeto podem ter acordos coletivos, podem utilizar estrutura matricial ou por outros motivos.
3.4.3 Desenvolver a equipe do projeto Este processo faz parte do grupo de processos de execução.
108 •
capítulo 3
Melhorar as competências e a interação de membros da equipe para aprimorar o desempenho do projeto. (VARGAS, 2009). Os principais objetivos desse processo é aumentar a capacidade dos membros da equipe do projeto e terminar as atividades por meio do aprimoramento de suas competências, aumento da coesão dos membros e melhoria do trabalho em equipe.
3.4.4 Gerenciar a equipe do projeto Este processo faz parte do grupo de processos de monitoramento e controle. Envolve o acompanhamento do desempenho de membros da equipe, o fornecimento de feedback, a resolução de problemas e a coordenação de mudanças para melhorar o desempenho do projeto. (PMI, 2012). Além do descrito no quadro acima, neste processo também temos a observação do comportamento da equipe executora, gerenciamento de conflitos, resolução de problemas e avaliação do desempenho dos membros da equipe. Basicamente, nesse processo todas as medições relativas à equipe do projeto são realizadas, alterações do plano de gerenciamento são solicitadas e as lições aprendidas são consolidadas (VARGAS, 2009). Ainda segundo Vargas (2009), no gerenciamento de recursos humanos, é importante que se atente para os seguintes aspectos: • O trabalho em time é vital para o sucesso do projeto; • O espírito de corpo contribui para o sucesso; • Conflitos podem ocorrer entre o projeto e a organização; • Qualquer promessa feita durante o recrutamento deve ser documentada; • Os níveis de equipes são muito mais variáveis em um ambiente de projeto que em um ambiente funcional; • Treinamento e desenvolvimento são mais complexos e críticos durante o projeto, se comparados com o trabalho tradicional da organização.
ATIVIDADES 01. De que forma o gerenciamento de tempo é importante para o sucesso de projetos? 02. Quais são os cinco processos do gerenciamento de tempo em projetos? 03. Uma vez definidas as atividades, quais devem ser os resultados?
capítulo 3
• 109
04. Porque é mais difícil estimar os tempos das atividades planejadas na área de TI? 05. Quais são as principais ferramentas para desenvolvimento do cronograma? 06. Faça o diagrama AOA para a seguinte escala de atividades:
ATIVIDADE
DEPENDÊNCIA
A
–
B
A,D
C
B,F
D
–
E
A,D
F
E,G,I
G
–
H
E,G,I
I
–
J
I
K
H,J
07. Qual é o elemento chave para controle do tempo, dentro do processo de monitoramento e controle?
REFLEXÃO Podemos notar até este ponto do nosso material, que todos os tipos de gerenciamento, seja de pessoas, de custos, de escopo – como vimos no capítulo anterior – são importantes, interdependentes e interdisciplinares, de modo que uma área mal planejada, pode comprometer todo um projeto, de modo que um olhar especial em todos os gerenciamentos e na sua eficaz gestão, pode ser o caminho para o sucesso!
110 •
capítulo 3
LEITURA Gestão de Custos em Projetos da Secretaria de Defesa Social de Minas Gerais, de Luiza Hermeto Coutinho Campos. Disponível em: Resumo do artigo: Este artigo dispõe sobre o gerenciamento de projetos no âmbito da Administração Pública, tendo em vista a escassez de material científico acerca desta metodologia gerencial sob a perspectiva não privada. Assim, o cerne do trabalho é o programa governamental Choque de Gestão, que trouxe a Gestão de Projetos ao Estado de Minas Gerais, no qual foram estabelecidas rotinas de monitoramento e instrumentos para gestão, baseados na Metodologia Estruturada de Planejamento e Controle de Projetos (MEPCP) para diversas áreas de conhecimento delimitadas pelo Project Management Body of Knowledge (PMBOK). Inserido neste contexto, o gerenciamento de custos é uma área basilar e complexa da gestão de projetos e, ao lidar com as diversas peculiaridades típicas da gestão orçamentária no setor público, a dificuldade é majorada. Para a pesquisa foi desenvolvido um estudo retrospectivo dos custos de um projeto da Secretaria de Estado de Defesa Social. Leia o artigo na íntegra pelo endereço: http://www.revistagep.org/ojs/index.php/ gep/article/view/242
LEITURA Modelo PMBOK/PMI para gestão de projetos nas micro e pequenas empresas: um estudo de caso, de Verônica Trentin Sella e Denize Grzybovski, 2011. Resumo: O objetivo deste artigo é analisar a possibilidade de empresas de micro e pequeno porte, no Brasil, adotarem o modelo de gestão de projetos PMBOK/PMI, com vistas a melhorar o desempenho e reduzir o índice de mortalidade dessas empresas. O modelo PMBOK/PMI fornece terminologia comum à gestão de projetos e inclui conhecimentos comprovados por práticas tradicionais, assim como conhecimentos por práticas inovadoras com aplicação limitada. Em termos metodológicos, esta é uma pesquisa exploratória, do tipo estudo multicaso e abordagem quanti/qualitativa dos dados coletados em entrevista e planilha de dados. Os dados revelam que as empresas pesquisadas possuem sistema superficial de gestão implantado, sem monitoramento das atividades e indicadores de resultados e sem as informações necessárias para gerir o negócio. Isso é uma dificuldade para a implantação do PMBOK/PMI, mas pode ser uma vantagem por criar controles e disciplina utilizando ferramentas de gestão, como cronograma e orçamentos. Também por projetos envolverem
capítulo 3
• 111
atividades não contínuas na empresa, existe o risco de o gestor “confundir” estas com as atividades do cotidiano e não conseguir avaliar o que pode ser gerido por projeto. Leia o artigo na íntegra pelo endereço: http://www.spell.org.br/documentos/ download/3028.
REFERÊNCIAS BIBLIOGRÁFICAS PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). Pennsylvânia: [s.n.], v. 3, 2004. PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4ª. ed. Pennsylvânia: [s.n.], 2008. Pons, R. (2009). Fundamentos em gerenciamento de projetos: módulo básico do curso de formação em gerenciamento de projetos. [Apostila de aula]. Rio de Janeiro: Projectlab. PRESSMAN, R. S. Engenharia de Software. USA: McGrawHill, 2006. SOMMERVILLE, I. Engenharia de Software. Rio de Janeiro: Addison Wesley, 2003. STANDISH GROUP, website acesso em setembro de 2015. http://www.standishgroup.com/about Valeriano, D. L. (1998). Gerência em projetos: pesquisa, desenvolvimento e engenharia. São Paulo: Makron Books. VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: Elsevier, 2007.
112 •
capítulo 3
4 Gerenciamento de Riscos, Comunicações, da Qualidade, do Gerenciamento de Aquisições e Partes Interessadas
O conceito de comunicação, atualmente, certamente um novo momento, de destaque, pois é um dos principais requisitos exigidos para os profissionais no mercado de trabalho. Capacidade de se comunicar claramente, saber passar e até mesmo administrar a informação são atitudes muito valorizadas Na área de Gestão de Projetos vemos essa característica mais claramente, onde o gestor precisa dominar tal artifício para que a informação possa ser recebida pela sua equipe ou cliente de forma clara e objetiva. É precisa considerar que a ideia de “comunicação” pode ter sofrido variações com o decorrer dos anos, antigamente a escrita era vista como a principal forma de comunicação. Hoje levamos em conta a comunicação corporal, comunicação oral, comunicação digital e é claro a escrita, todas essas formas de comunicação podem ser vistas, por exemplo, no gerenciamento de projetos o qual é o foco deste artigo. Dando continuidade aos tipos de gerenciamento de projetos com base nas áreas de conhecimento, neste capítulo vamos ver os gerenciamentos de riscos, comunicações, aquisições, qualidade e partes interessadas. Vamos lá!
OBJETIVOS • Conceituar as áreas de riscos, aquisições, stakeholders e comunicações • Apresentar o detalhamento de cada uma dessas áreas de conhecimento do PMI; • Conhecer as técnicas e ferramentas desses tipos de gerenciamento.
114 •
capítulo 4
4.1 Gerenciamento das Comunicações O gerenciamento de comunicação do projeto é a área de conhecimento que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações sobre o projeto de forma oportuna e adequada. (PMBOK, 2008 e 2012). Há quem diga que o gerente de projetos gasta 90% do seu tempo se comunicando. Ele deve se comunicar com todos os stakeholders do projeto, mostrando o desempenho do projeto, relatórios de acompanhamento, definindo escopo entre outros. A arte da comunicação, competência necessária no gerenciamento de projetos, é algo que vai além do escopo do ciclo de gerenciamento de projetos e inclui atividades como: modelos emissor-receptor, escolha dos meios de comunicação, estilo de redação, técnicas de apresentação, técnicas de gerenciamento de reuniões e outros. Sempre que pensamos em gerenciamento de projetos, logo, pensamos em administração de tempo, escopo e qualidade, na verdade, a administração de todas estas áreas requer do gerente de projeto uma gama de habilidades e técnicas efetivas, pois muitos elementos precisam ser coordenados. Manter um time unido e sólido, e atender as expectativas dos stakeholders é um dos grandes desafios que um gerente de projeto enfrenta. Um bom plano de comunicação pode ser chave para que a execução e o controle do projeto tenham sucesso. O desenvolvimento de um plano de comunicação envolve vários fatores como eles administração de informação, expectativa dos stakeholders, a precisão das informações entre outros. Durante todo o ciclo de vida de um projeto, é produzida ou recebida, uma grande quantidade de informações. A administração desta informação é a responsabilidade do gerente de projeto. Em um plano de comunicação, é necessário identificar de forma clara como uma informação será gerada e distribuída. Portanto, é responsabilidade desta área de conhecimento fornecer as ligações entre pessoas e informações adequadas, sendo que entenderemos como pessoas todos os stakeholders do projeto, como partes interessadas, cliente e patrocinador. Um efetivo processo de comunicação é necessário para garantir que todas as informações desejadas cheguem às pessoas corretas no tempo certo e de
capítulo 4
• 115
uma maneira economicamente viável. O gerente de projeto utiliza-se da comunicação para assegurar que o time do projeto trabalhe de maneira integrada para resolver os problemas do projeto e aproveitar suas oportunidades. Vargas (2009), define a comunicação como um processo pelo qual a informação é transferida entre os indivíduos através de símbolos, sinais e outros. Além disso, a comunicação é um processo de duas vias, onde participam ativamente o emissor e o receptor da informação, com os envolvidos atuando, na maioria das vezes, como emissores e receptores simultaneamente. Então, para buscar a efetiva comunicação entre os stakeholders do projeto e o trânsito adequado de informações, o ciclo de vida de projetos prevê 4 processos de gerência de comunicação, sendo 1 de iniciação, 1 de planejamento, 1 de execução e 2 de monitoramento e controle, a saber: 1. Iniciação a) Identificar as partes interessadas; 2. Planejamento a) Planejar as comunicações; 3. Execução a) Distribuir as informações; b) Gerenciar as expectativas das partes interessadas. 4. Monitoramento e controle a) Reportar o desempenho.
4.1.1 O Processo de Comunicação O processo de comunicação é composto de três etapas subdivididas: 1. Emissor: é a pessoa que pretende comunicar uma mensagem, pode ser chamada de fonte ou de origem. a) Conceito: corresponde à ideia, ao significado que o emissor deseja comunicar. b) Codificação: é constituído pelo mecanismo vocal para decifrar a mensagem. 2. Mensagem: é a ideia em que o emissor deseja comunicar. a) Canal: também chamado de veículo, é o espaço situado entre o emissor e o receptor. b) Ruído: é a perturbação dentro do processo de comunicação.
116 •
capítulo 4
3. Receptor: é a etapa que recebe a mensagem, a quem é destinada. a) Descodificação: é estabelecido pelo mecanismo auditivo para decifrar a mensagem, para que o receptor a compreenda. b) Compreensão: é o entendimento da mensagem pelo receptor. c) Reação: o receptor confirmar a mensagem recebida do emissor representa a volta da mensagem enviada pelo emissor (Feedback). Com base nos trabalhos de Mintzberg sobre as estruturas das organizações, podem ser estabelecidos alguns fluxos no processo de trabalho provocados por diferentes mecanismos de comunicação entre as pessoas dentro de uma organização. São eles: • Fluxo da Autoridade Formal - Onde a informação flui segundo uma hierarquia instituída dentro da organização ou projeto, realçando o fluxo do poder formal. • Fluxo da Atividade Regulamentada – Onde a informação flui segundo um mecanismo padronizado de informação independente da hierarquia dos envolvidos. O foco desse fluxo é a padronização do processo de comunicação. • Fluxo das Comunicações Informais – Onde o processo de comunicação se dá sem a presença de nenhuma estrutura reguladora. As pessoas se agregam em grupos sociais ou de relacionamento e neles não existe hierarquia ou padronização. É o mais veloz e o mais arriscado mecanismo de comunicação. • Conjunto das Constelações de Trabalho – Onde o processo de comunicação se dá através de objetivos claros e adequados a cada nível hierárquico da estrutura. Normalmente, as constelações de trabalho são os melhores modelos para o desenvolvimento do processo de comunicação em projetos. • Fluxo do Processo Decisório Específico – Onde o processo de comunicação é necessário para decisões específicas, partindo da geração do problema até chegar à decisão específica a ser tomada.
4.1.2 Como Identificar um bom plano de comunicação Devemos identificar de forma clara como uma informação será gerada e distribuída. Este plano deveria identificar os tipos de relatórios (relatórios formais, status do projeto, memorandos, etc.), a frequência que os relatórios serão gerados, e em que momento deverá acontecer às reuniões.
capítulo 4
• 117
4.1.3 Planejamento das Comunicações segundo o PMBOK “O processo Planejamento das Comunicações determina as necessidades de informações e comunicações das partes interessadas; por exemplo, quem precisa de qual informação, quando precisarão dela, como ela será fornecida e por quem. Embora todos os projetos compartilhem a necessidade de comunicar as informações sobre o projeto, as necessidades de informações e os métodos de distribuição variam muito. Um fator importante para o sucesso do projeto é identificar as necessidades de informações das partes interessadas e determinar uma maneira adequada para atender a essas necessidades.”[...]“O planejamento das comunicações está, muitas vezes, estreitamente ligado aos fatores ambientais da empresa e às influências organizacionais, pois a estrutura organizacional do projeto terá um efeito importante nos requisitos de comunicações do projeto.(PMBOK, 2012).
4.1.4 Processo de Gerenciamento da Comunicação O processo de gerenciar a comunicação pode ser considerado tão importante quanto qualquer outro processo dentro da empresa. Os gerentes gastam a maior parte do seu tempo em comunicação e muitas vezes nem percebem o impacto que uma comunicação bem feita implica positivamente no projeto. O avanço da tecnologia da informação permite que as empresas registrem de forma eficiente as informações de seus projetos. Mas, o que fazer com tanta informação? O fato de registrar bem os dados do projeto não garante sua utilidade. Perdidos em meio a tantos registros, saber usá-los de forma eficaz não é tarefa fácil se não houver um bom planejamento e uma forma de gestão da comunicação implementada. As empresas preocupam-se com seus processos. Buscam formas de medir seus desempenhos, estabelecem rotinas de reuniões gerenciais, criam formulários e relatórios extensos e “bem estruturados”. Com tudo isto, somando à facilidade de preservar as informações em formato eletrônico gera um acúmulo de dados cada vez maior. Mas, quando necessário uma consulta, o resgate da informação pode ser uma missão quase impossível. Planejar as comunicações Este processo faz parte do grupo de processos de planejamento.
118 •
capítulo 4
Determina as necessidades de informações das partes interessadas. (PMBOK, 2008). Este processo tem por responsabilidade determinar as necessidades de informações no que diz respeito a definição de quem precisa da informação, em que formato ela deve ser provida e em que tempo ela deve estar disponível. Ou seja, em relação às informações, busca responder às seguintes questões: Quem precisa? Quando precisa? Como precisa? Quem deve informar? Distribuir as informações Este processo faz parte do grupo de processos de execução. Envolve colocar as informações à disposição das partes interessadas e no momento oportuno. (PMBOK, 2004 e 2008). Este processo tem por responsabilidade principal colocar em prática o plano de comunicações do projeto, disponibilizando as informações para as pessoas corretas, no momento correto e no nível adequado. Gerenciar as expectativas dos stakeholders do projeto Este processo faz parte do grupo de processo de execução. Como dito acima, no processo de identificar as partes interessadas, é função do gerente de projetos influenciar as partes interessadas afim de aumentar a probabilidade de sucesso do projeto. Dessa forma, este processo cuida exatamente desta influência e tem por objetivo a execução de comunicações e interações com as partes interessadas, visando a atender as expectativas dessas partes e solucionar questões problemáticas, conforme elas venham a ocorrer. (PMBOK, 2008). Esse gerenciamento pode se dar de várias formas: • Gerenciamento ativo das partes interessadas, no qual o gerente de projetos deve negociar e influenciar o desejo dessas partes de forma a diminuir a não aceitação (quando ela existir). • Prever possíveis problemas que essas partes interessadas podem trazer e efetuar a análise de riscos. • Buscar a solução de problemas identificados com as partes interessadas.
capítulo 4
• 119
De fato, o grande objetivo deste processo é utilizar a identificação e o entendimento sobre as partes interessadas para antever suas reações a certas questões do projeto e, com isso, buscar alternativas preventivas para conseguir o apoio (ou minimizar obstáculos) dessas partes interessadas frente a essas questões. (PMBOK, 2008). Reportar o Desempenho Este processo faz parte do grupo de processos de monitoramento e controle. Envolve a coleta de todos os dados de linha de base e a distribuição das informações sobre o desempenho às partes interessadas. (PMBOK, 2004 e 2008). Este processo tem por responsabilidade gerar relatórios de desempenho sobre várias áreas do projeto, como, por exemplo: escopo, cronograma, custo e qualidade. Também, este processo informa as pessoas corretas com os documentos corretos e no nível de detalhe correto (entenda correto como planejado).
REFLEXÃO No gerenciamento das comunicações, é importante que se atente para os aspectos a seguir: • As pessoas dão o melhor de si quando compreendem completamente as decisões que as afetam e suas razões. Elas precisam perceber o que têm de fazer e o porquê, o seu desempenho em relação ao esperado e a sua situação profissional; • se a base do gerenciamento de projetos é a formalização de processos para alcançar melhor desempenho, a informação e a comunicação não podem ser relegadas ao improviso e à intuição; • a decisão sobre o que comunicar, para quem e como deve ser incorporada a todas as fases do planejamento; • os diferentes veículos de comunicação se complementam, combinando mensagens gerais e específicas para atingir diversos públicos; • informe sempre, em ocasiões regulares e com honestidade. Isso cria credibilidade para o processo; • nas situações de crise, seja ágil. Informe a posição atual, ainda que não seja a definitiva. Ninguém gosta de saber por último, e a falta de informações é fonte para boatos, criando instabilidade no projeto; • as pessoas não têm de concordar para cooperar com uma decisão, mas têm de compreender como e por que ela foi tomada.
120 •
capítulo 4
4.2 Gerenciamento de Riscos Segundo Vargas (2009), na maioria dos projetos, os riscos associados com grandes empreendimentos têm merecido uma atenção especial dos gerentes de projeto, devido não só às grandes somas de dinheiro que estão em suas mãos, como também à reputação do time e dos patrocinadores do projeto. Gerenciamento de riscos possibilita a chance de melhor compreender a natureza do projeto, envolvendo os membros do time de modo a identificar as potenciais forças e riscos do projeto e responder a eles, geralmente associados a tempo, qualidade e custos. Portanto, a sobrevivência de qualquer empreendimento, atualmente, está intimamente vinculada ao conceito de aproveitar uma oportunidade, dentro de um espectro de incertezas. O que torna a gestão dos riscos se tornar tão importante são fatores diversos, como o aumento da competitividade, o avanço tecnológico e as condições econômicas, que fazem com que os riscos assumam proporções muitas vezes incontroláveis. O gerenciamento de riscos do projeto inclui os processos que tratam da realização de identificação, análise, respostas, monitoramento e controle, e planejamento do gerenciamento de riscos em um projeto. (PMBOK, 2008). Segundo o PMBOK (2008), quando se trata de riscos é importante identificar a probabilidade e o impacto de um determinado evento acontecer. Também é importante determinar se o evento será negativo ou positivo para o projeto. Isso por que há alguns riscos que trazem impactos positivos para o projeto e o gerente de projetos deve buscar aumentar a probabilidade disso acontecer. Por isso, os processos envolvidos nesta área de conhecimento têm por objetivos principais aumentar a probabilidade e o impacto de eventos positivos e diminuir a probabilidade e o impacto dos eventos negativos. Para atingir a esses objetivos, o gerenciamento de riscos conta com 6 processos, sendo 5 processos de planejamento e 1 de monitoramento e controle, a saber: 1. Planejar o gerenciamento de riscos 2. Identificar os riscos 3. Realizar a análise qualitativa de riscos 4. Realizar a análise quantitativa de riscos 5. Planejar as respostas a riscos 6. Monitorar e controlar os riscos. Vamos a cada um deles! capítulo 4
• 121
4.2.1 Planejar o gerenciamento de riscos Este processo faz parte do grupo de processos de planejamento. É o processo de decidir como conduzir as atividades de gerenciamento de riscos de um projeto. (PMBOK, 2008). Neste processo é que será planejado como os riscos serão tratados durante todo o projeto. Por isso, os outros 5 processos de gerenciamento de riscos dependem do bom desenvolvimento deste processo. Este processo é importante para garantir que o tratamento do risco no projeto esteja de acordo com o nível estratégico que o projeto tem para a organização, pois somente dessa maneira, tempo e recursos adequados serão desviados de forma coerente para as ações de gerenciamento de riscos do projeto.
4.2.2 Identificar os riscos Este processo faz parte do grupo de processos de planejamento. Determina e documenta as características dos riscos que podem afetar o projeto. (PMBOK, 2008). Este processo é responsável por gerar uma listagem contendo todos os riscos identificados, possíveis respostas para os riscos e causas / raízes dos riscos.
4.2.3 Realizar a análise qualitativa de riscos Este processo faz parte do grupo de processos de execução. Este processo inclui métodos de priorização dos riscos identificados (por meio de análise de probabilidade e impacto) para ação adicional, como análise quantitativa dos riscos ou planejamento de repostas a riscos. (PMBOK, 2008). Por meio principalmente da probabilidade do risco acontecer e de seu impacto, este processo tem por finalidade priorizar os riscos configurando-se como uma maneira bastante barata de fazê-lo. Esses riscos priorizados servirão de entrada para o processo de planejamento de respostas aos riscos. O processo de análise quantitativa e o processo de resposta a riscos são processos mais morosos e caros, e por isso o processo de realizar a análise qualitativa de riscos funciona como um filtro afim de escolher os processos que são realmente problemáticos para o projeto.
122 •
capítulo 4
4.2.4 Realizar a análise quantitativa de riscos Este processo faz parte do grupo de processos de planejamento. Este processo analisa o efeito dos eventos de riscos e atribui uma classificação numérica a esses riscos. (PMBOK, 2004 e 2008). Este processo deve ser aplicado apenas para os riscos que foram priorizados pelo processo de análise qualitativa dos riscos e é responsável por quantificar esses riscos.
4.2.5 Planejar as respostas a riscos Este processo faz parte do grupo de processos de planejamento. É o processo de desenvolver opções e determinar ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto e segue os processos de análise qualitativa e quantitativa dos riscos do projeto. (PMBOK, 2008). Este processo busca “soluções” para os riscos identificados e designa pessoas que serão responsáveis por cada resposta a esses riscos.
4.2.6 Monitorar e Controlar os riscos Este processo faz parte do grupo de processos de monitoramento e controle. É o processo responsável por colocar em prática os planos de resposta aos riscos e monitorar os resíduos dos riscos que já acontecem, acompanhar os riscos que ainda não aconteceram e identificar novos riscos durante todo o ciclo de vida do projeto. (PMBOK, 2008). Portanto, este processo tem o objetivo de monitorar as respostas aos riscos bem como o surgimento de novos riscos e os riscos residuais de riscos que já ocorreram.
4.3 Gerenciamento das Aquisições O gerenciamento das aquisições tem como objetivo dar garantia ao projeto de que todo elemento externo participante do projeto irá garantir o fornecimento de seu produto, ou serviço, para o projeto.
capítulo 4
• 123
A relação entre o fornecedor e o projeto é determinada usualmente pela quantidade de riscos incorridos pelas partes. Normalmente, o custo de um determinado suprimento, ou contrato, está diretamente relacionado com o risco associado àquele trabalho. Por causa desse fator de risco, muitas vezes o custo não é o único elemento a ser analisado na negociação. O tipo de contrato também passa a determinar um papel fundamental no processo. Cada tipo de contrato representa certo grau de incerteza e riscos para o gerente de projeto (VARGAS, 2009) O gerenciamento de aquisições do projeto inclui os processos para comprar ou adquirir os produtos, serviços ou resultados necessários para o projeto, mas de fora da equipe do projeto, sendo que a organização executora do projeto pode ser o comprador ou fornecedor do produto. (PMBOK, 2008). Como dito acima, o gerenciamento de aquisições é o responsável por gerenciar os contratos e alterações de contrato que a organização executora tem com fornecedores ou que a organização executora tem com clientes para os quais ela fornece o projeto (ou seus produtos) que está sendo executado (no caso da organização executora ser contratada externa para a execução do projeto). Para realizar a gerência desses contratos, a área de conhecimento de gerenciamento de aquisições contém 4 processos, sendo 1 de planejamento, 1 de execução, 1 de monitoramento e controle e 1 de encerramento, a saber: 1. Planejar aquisições 2. Conduzir as aquisições 3. Administração as aquisições 4. Encerrar as aquisições Vamos a cada um deles:
4.3.1 Planejar as Aquisições Este processo faz parte do grupo de processos de planejamento Foca as decisões de compra do projeto de forma a documentá-las, especificar a abordagem utilizada para a compra e identificar os potenciais fornecedores que poderá oferecer o produto/serviço. (PMBOK, 2008). Além disso, este processo busca nas atividades do projeto àquelas que poderiam ser melhores atendidas por meio de aquisição externa de produtos e/ ou serviços.
124 •
capítulo 4
Concluindo, este processo é utilizado para determinar quais apoios externos serão contratados e de que forma essa contratação irá ocorrer. Dessa forma, esse processo também acaba englobando a seleção de fornecedores.
4.3.2 Conduzir as Aquisições Este processo continua o processo anterior buscando respostas de fornecedores selecionados e selecionando um fornecedor, com o qual o contrato será assinado, para a execução da aquisição em questão. (PMBOK, 2008). De forma bastante resumida, este processo é responsável por negociar as aquisições com todos os fornecedores e, por meio de um critério sistematizado, buscar a seleção de um fornecedor (para cada aquisição) assinando contrato com o mesmo
4.3.3 Administrar as Aquisições Este processo faz parte do grupo de processos de monitoramento e controle. O comprador e o fornecedor administram contrato com objetivos semelhantes. Cada uma das partes garante que tanto ela quanto a outra parte atendam às suas obrigações contratuais e que seus próprios direitos legais estejam protegidos. (PMBOK, 2008). Este processo busca garantir que o fornecedor atenda ao contrato bem como o comprador.
4.3.4 Encerrar as Aquisições Este processo faz parte do grupo de processos de encerramento. Busca realizar a finalização de cada aquisição feita no projeto. Por isso, acaba dando suporte ao processo Encerrar o projeto, pois envolve a confirmação de que todo o trabalho e as entregas foram aceitas. (PMBOK, 2008). Este processo é responsável pela finalização de todos os contratos e registros de informações em bases históricas sobre os contratos e fornecedores. Este processo também trata sobre a rescisão de contratos.
capítulo 4
• 125
4.4 Gerenciamento dos Stakeholders – Partes Interessadas O Gerenciamento das partes interessadas do projeto inclui os processos exigidos para identificar todas as pessoas, grupos ou organizações que podem impactar ou serem impactados pelo projeto, analisar as expectativas das partes interessadas e seu impacto no projeto, além de desenvolver estratégias de gerenciamento apropriadas para o envolvimento eficaz das partes interessadas nas decisões e execução do projeto (MARTINS, 2013). O gerenciamento das partes interessadas também se concentra na comunicação contínua com as partes interessadas para entender suas necessidades e expectativas, abordando as questões conforme elas ocorrem, gerenciando os interesses conflitantes e incentivando o comprometimento das partes interessadas com as decisões e atividades do projeto (MARTINS, 2013). Os processos e principais produtos de Gerenciamento das partes interessadas são:
PROCESSOS
• Identificar as partes interessadas.
PRINCIPAIS PRODUTOS
• Estratégias para gerenciamento das partes interessadas.
• Planejar o gerenciamento das partes
• Plano de gerenciamento das partes
interessadas.
interessadas.
• Gerenciar o envolvimento das partes
• Sistema de informações gerenciais.
interessadas.
• Controlar o envolvimento das partes
• Estratégia e planos para o envolvimen-
interessadas.
to das partes interessadas.
126 •
capítulo 4
4.4.1 Identificar as partes Interessadas As partes interessadas são pessoas e organizações, tais como clientes, patrocinadores, a organização executora e o público, que estão ativamente envolvidas no projeto ou cujos interesses podem ser positiva ou negativamente afetados pela execução ou pelo término do projeto(MARTINS, 2013). Envolver as partes interessadas no início do projeto aumenta a probabilidade de aceitação das entregas do projeto, haja vista que as partes interessadas são utilizadas para mapear o escopo do projeto e os requisitos do produto. A maioria dos projetos tem um grande número de partes interessadas. Como o tempo do gerente de projetos é limitado e precisa ser usado com a maior eficiência possível, essas partes interessadas devem ser classificadas de acordo com o interesse, a influência e o envolvimento no projeto. Isso permite que o gerente de projetos se concentre nos relacionamentos necessários para garantir o sucesso do projeto. Também podem exercer influência sobre o projeto e suas entregas. As partes interessadas podem estar em diversos níveis da organização e ter diferentes níveis de autoridade, ou ser externas à organização executora do projeto (MARTINS, 2013).
4.4.2 Planejar o gerenciamento das partes interessadas Planejar o gerenciamento das partes interessadas é o processo de desenvolver estratégias apropriadas de gerenciamento para envolver as partes interessadas de maneira eficaz no decorrer de todo o ciclo de vida do projeto, com base na análise das suas necessidades, interesses, e impacto potencial no êxito do projeto. O gerenciamento das partes interessadas significa mais do que melhorar as comunicações e requer mais do que gerenciar uma equipe, envolve a criação e manutenção de relacionamentos entre a equipe do projeto e as partes interessadas, com o objetivo de satisfazer suas respectivas necessidades e requisitos dentro dos limites do projeto (MARTINS, 2013). À medida em que o projeto avança, a comunidade das partes interessadas e o nível exigido de envolvimento podem mudar. O nível de envolvimento das partes interessadas pode ser classificado como: • Desinformado: sem conhecimento do projeto e impactos potenciais. • Resistente: ciente do projeto e dos impactos potenciais e resistente à mudança. capítulo 4
• 127
• Neutro: ciente do projeto e mesmo assim não dá apoio ou resiste. • Dá apoio: ciente do projeto e dos impactos potenciais e dá apoio à mudança. • Lidera: ciente do projeto e dos impactos potenciais e ativamente engajado em garantir o êxito do projeto.
4.4.3 Gerenciar o envolvimento das partes interessadas O processo Gerenciar o envolvimento das partes interessadas envolve as atividades de comunicação dirigidas às partes interessadas para influenciar suas expectativas, abordar as preocupações e solucionar as questões, tais como: • Gerenciar ativamente as expectativas das partes interessadas para aumentar a probabilidade de aceitação do projeto, negociando e influenciando seus desejos para alcançar e manter as metas do projeto. • Envolver as partes interessadas nas etapas apropriadas do projeto para obter ou confirmar seu compromisso continuado com o êxito do projeto. • Abordar as preocupações que ainda não se tornaram questões, geralmente relacionadas com a prevenção de futuros problemas. Essas preocupações precisam ser reveladas e analisadas e os riscos precisam ser avaliados. • Esclarecer e solucionar as questões que foram identificadas. A solução pode resultar em uma solicitação de mudança ou pode ser tratada fora do projeto como, por exemplo, ser adiada para outro projeto ou fase, ou transferida para outra entidade organizacional. O gerenciamento do envolvimento das partes interessadas ajuda a aumentar a probabilidade de sucesso do projeto, garantindo que as partes interessadas entendam claramente as metas, os objetivos, os benefícios e os riscos do projeto (MARTINS, 2013). Em geral, o gerente de projetos é responsável pelo gerenciamento das partes interessadas.
4.4.4 Controlar o nível de comprometimento das partes Interessadas Controlar o nível de comprometimento das partes interessadas é o processo de monitorar os relacionamentos das partes interessadas no projeto em geral e ajustar as estratégias e planos para o engajamento das mesmas. O principal
128 •
capítulo 4
benefício desse processo é a manutenção ou aumento da eficiência e eficácia das atividades de engajamento das partes interessadas à medida que o projeto se desenvolve e o seu ambiente muda (MARTINS, 2013). As informações usadas no processo Controlar o nível de comprometimento das partes interessadas incluem, entre outras: • Como o trabalho será executado para completar os objetivos do projeto. • Como os requisitos de recursos humanos serão cumpridos, como os papéis e responsabilidades, a estrutura hierárquica e o gerenciamento do pessoal serão abordados e estruturados para o projeto. • Um plano de gerenciamento de mudanças que documenta como as mudanças serão monitoradas e controladas. • Necessidades e técnicas para a comunicação entre as partes.
ATIVIDADES 01. Quais as diferenças na aplicação da análise qualitativa e quantitativa de riscos? 02. Explique qual a importância do gerenciamento de riscos? 03. Por que devemos nos preocupar com a comunicação entre os envolvidos no projeto? O que pode ocorrer que comprometa o processo de comunicação, por exemplo? 04. Cite alguns sujeitos que são considerados stakeholders do processo de gerenciamento de projetos e explique por que eles são importantes para o sucesso do projeto? 05. Explique os elementos 5W e 2H para a criação do plano de comunicação do projeto.
REFLEXÃO Como já foi dito em outros momentos do livro, gerenciar projetos buscando seu sucesso e eficácia, não possui receita de bolo, que fará com que o projeto ocorra e finalize exatamente como foi previsto e conforme foi escrito. Intercorrências acontecem, e quanto maior for o grau de complexidade de um projeto, maior a probabilidade de intercorrências ele terá. Assim, ter muito claramente a necessidade de um acompanhamento e monitoramento minucioso do projeto, seja por parte do gerente de projeto, seja por parte dos envolvidos, pode
capítulo 4
• 129
não assegurar sucesso garantido, mas com certeza, dará muito mais segurança em buscar esse resultado no final do processo. E todas as áreas são importantes, cada qual com sua influência no projeto como um todo!
LEITURA IMPLANTAÇÃO DE PROJETOS DE SISTEMAS NA ÁREA DE SERVIÇOS: AVALIAÇÃO DA GESTÃO DE STAKEHOLDERS. Autores: Elisabete Cecília Januário Chaves, Rosemeire Oikawa, Napoleão Verard Galegale, Marília Macorin de AzevedoArtigo Resumo: A área de conhecimento “Gestão de Stakeholders” em ambientes de implantação de projetos de sistemas na área de serviços vem ganhando espaço entre os gestores de projeto. Este artigo visa avaliar os benefícios trazidos por essa área de conhecimento segundo opiniões de especialistas em gestão de projetos. Para essa avaliação utilizou-se uma pesquisa com o método Delphi, além de considerar referências bibliográficas e melhores frameworks em Gerenciamento de Projetos. Nessa nova área de conhecimento, os grupos de processos recomendam boas práticas em procedimentos para a gestão dos interessados buscando contribuir para o sucesso na implementação de projetos. Disponível no endereço: interessadas, recomendo fortemente que abra. http://repositorio.enap.gov.br/handle/1/1098.
REFERÊNCIAS BIBLIOGRÁFICAS MARTINS, Carlos Eduardo. 2013. Gerência de Projetos – Teoria e Prática. Disponível em: http://repositorio.enap.gov.br/bitstream/handle/1/1098/GerenciaDeProjeos_modulo_4_final_. pdf?sequence=1&isAllowed=y – acesso setembro de 2015 PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania: s.n., 2008. PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4ª. ed. Pennsylvânia: [s.n.], 2008. PRESSMAN, R. S. Engenharia de Software. USA: McGrawHill, 2006. SOMMERVILLE, Ian.. Engenharia de software. Rio de Janeiro: Addison Wesley, 2003. VARGAS, Ricardo.. Site do Ricardo Vargas. . Acesso em:16 mar. 2010.
130 •
capítulo 4
VIEIRA, Marconi Fábio.. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro: Elsevier, 2007. Pons, R. (2009). Fundamentos em gerenciamento de projetos: módulo básico do curso de formação em gerenciamento de projetos. [Apostila de aula]. Rio de Janeiro: Projectlab. VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: Elsevier, 2007.
capítulo 4
• 131
132 •
capítulo 4
5 A Qualidade Num Projeto e o Processo de Gerenciamento da Qualidade
O gerenciamento da qualidade do projeto inclui todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade de modo que o projeto atenda às necessidades que motivaram sua realização. Porém, antes de falarmos de qualidade em projetos, precisamos entender o conceito de Qualidade, suas origens, os chamados gurus da qualidade, para depois disso, poder compreender sua importância no gerenciamento de projetos. Vimos que gerenciamento da qualidade é, portanto, uma das 10 áreas de conhecimento do processo de gerenciamento de projetos do guia PMBOK e será, neste capítulo, trabalhado de forma isolada, devido seu grau de importância para o projeto como um todo. Veremos que o conceito de qualidade está ligado ao atendimento dos requisitos dos stakeholders do projeto. Esses requisitos podem ser do produto ou do projeto.
OBJETIVOS • Definir termos e conceitos da qualidade; • Reconhecer as diferentes visões de qualidade; • Identificar o contexto de aplicabilidade das diferentes contribuições dos autores da qualidade; • Entender a evolução da qualidade nas organizações. • Discutir a relação que se estabelece entre qualidade e as especificações de um projeto. • Apresentar as etapas necessárias para se construir um plano de gerenciamento da qualidade aplicada ao desenvolvimento de um projeto • Compreender os passos necessários para a elaboração de um plano de gerenciamento da qualidade de um projeto.
COMENTÁRIO Qualidade é um termo que está incorporado ao nosso dia a dia, sendo empregado na compra, venda e uso de produtos e serviços, embora nem sempre com o mesmo significado. Há uma grande subjetividade em torno da palavra, que pode ser conceituada de diferentes maneiras, como por exemplo: ausência de defeitos, melhor desempenho, capacidade de atender a uma necessidade específica, capacidade de personalização, diversidade de atributos de um produto/serviço, entre outras. Dada a amplitude do termo, é conveniente defini-lo ao
134 •
capítulo 5
interlocutor sempre que o mesmo for utilizado para que não haja confusão na compreensão de seu significado. Observa-se que a polêmica em torno da ideia de qualidade vem de longa data. Os primeiros registros estão relacionados ao Império Grego. Os filósofos gregos discutiram a ideia de qualidade ligada ao conceito de excelência ou superioridade moral, intelectual e física (MAXIMIANO, 2006). Posteriormente, já bem mais tarde, no século XVIII, vamos encontrar a sociedade fundamentada na ideia noção de qualidade associada a valor, ligando o conceito a produtos caros de luxo e alto desempenho, que poucas pessoas podem comprar (GARVIN, 1992). Com a Revolução Industrial e o advento da Administração Científica, Taylor, trouxe para as empresas uma série de inovações do ponto de vista técnico: divisão do trabalho, padronização das atividades executadas na produção do produto, simplificação dos movimentos requeridos pelo trabalhador para a execução de uma determinada tarefa, estabelecimento de um tempo padrão para realização de cada atividade, definição de uma meta de produção para cada trabalhador, melhoria dos métodos e das ferramentas de trabalho (MAXIMIANO, 2006). Seguindo a linha de pensamento de Taylor, Ford investiu na produtividade da linha de produção, através da especialização total do trabalho (CERTO, 2003), na criação do sistema de produção em massa (RIBEIRO, 2003) e da simplificação das peças utilizadas na montagem do automóvel, tornando-as padronizadas e intercambiáveis (LACOMBE; HEILBORN, 2003). Com esses incrementos, muda-se o foco sobre o conceito de qualidade que passa a ser relacionado ao processo de produção, adquirindo um caráter quantitativo, inerente aos erros e as falhas dos processos produtivos. Atualmente, a qualidade pode ser definida como um critério estratégico de diferenciação competitiva, no qual a organização tem como objetivo oferecer ao mercado produtos/serviços melhores do que os concorrentes (SLACK, 1997).
capítulo 5
• 135
5.1 Visões da Qualidade Desde a Revolução Industrial, vários autores tentaram definir qualidade. A conclusão que se chegou é que o conceito de qualidade é subjetivo, ou seja, não pode ser expresso, numa frase única, dada a sua complexidade e seu caráter multidimensional. Assim, alguns autores se ocuparam em sintetizar as diversas maneiras pelas quais a qualidade pode ser vista. Talvez essa diversidade de definições sobre o assunto, seja consequência da própria evolução da gestão da qualidade ao longo deste século (TOLEDO; CARPINETTI, 2000). O importante é lembrar que elas se complementam entre si! Garvin (1992) destaca cinco dimensões para definir qualidade: • Transcendental – conceitua qualidade como excelência nata, constituindo-se numa propriedade absoluta e universalmente reconhecível; • Baseada no produto – define qualidade como uma variável precisa, mensurável e diretamente relacionada aos atributos do produto, podendo ser avaliada objetivamente. Nessa abordagem, um maior nível de qualidade exige maior custo, portanto produtos de maior qualidade estão associados a produtos com maior preço; • Baseada no usuário – associa qualidade a preferências pessoais. Portanto, quanto maior a satisfação do cliente maior o nível de qualidade; • Baseada na produção– tem como foco a engenharia, desta forma, qualidade significa conformidade com às especificações; • Baseada no valor – conceitua qualidade como o equilíbrio entre custo e preço, ou seja, um produto de qualidade deve apresentar o desempenho esperado a um custo e preço aceitável.
5.2 Conceitos de Qualidade segundo Deming Deming foi um dos principais precursores do conceito e do desmembramento da qualidade na história da gestão de negócios. Suas contribuições já ensinadas e aplicadas até hoje pelo seu caráter inovador e moderno. Willian Edwards Deming nasceu em 1900, em Sioux City, Iowa, Estados Unidos. Em 1921 licenciou-se em Física, na Universidade do Wyoming e, em
136 •
capítulo 5
1928, doutorou-se em Matemática pela Yale University. Em 1950, foi convidado pela JUSE (Japan Union of Scientists and Engineers) para dirigir ações de formação em estatística e controle de qualidade no Japão (SPINER, 2008). O impacto das suas ideias junto ao empresariado japonês foi tão grande, que Deming é considerado um dos responsáveis pela retomada do desenvolvimento do país pós Segunda Guerra mundial (CARAVANTES; PANNO; KLOECKNER, 2005). A década de 1970 foi marcada pela expansão da economia japonesa e sua penetração nos mercados ocidentais, especialmente através das indústrias eletrônica e automobilística. Esse crescimento despertou o interesse por parte dos ocidentais em entender as razões do “milagre” japonês. A reação foi de perplexidade quando se descobriu que muitos japoneses atribuíam a um americano, desconhecido em seu próprio país – Deming – grande parte das razões de seu sucesso. Somente a partir daí, é que os Estados Unidos passaram a valorizar os ensinamentos de Deming (MAXIMIANO, 2006). Em 1982, Deming publicou o livro Quality, productivity and competitive position (Qualidade, produtividade e posição competitiva), que discorre sobre como administrar a qualidade (RIBEIRO, 2003). Em 1986, Reagan atribuiu a Deming a National Medal of Technology (Medalha Nacional de Tecnologia), e nesse mesmo ano, o estudioso lançou o livro Out of Crisis (Saia da Crise), a obra que o consagrou como o grande mestre da qualidade, definindo os 14 princípios para o desenvolvimento de um programa de gestão da qualidade, que estão descritos um pouco mais à frente (MAXIMIANO, 2006). Durante mais de 40 anos, Deming trabalhou como consultor, escritor e professor da Stern School of Business (Nova Iorque), morrendo aos 93 anos (SPINER, 2008). Deming estruturou sua filosofia de administração da qualidade baseada nos seguintes fatores críticos à competitividade de uma empresa (TOLEDO 2000): Falta de envolvimento dos setores da administração com os problemas da produção; • A qualidade era encarada como responsabilidade exclusiva da produção; • O treinamento do pessoal era completamente inadequado para tratar problemas relacionados com a qualidade; • Utilização da inspeção como forma prioritária de garantia da qualidade. Com base nestes aspectos críticos, Deming estabeleceu um conjunto de 14 princípios que serviram de base para o estabelecimento de um programa da qualidade (MAXIMIANO, 2006): capítulo 5
• 137
• Princípio 1 – melhoria contínua de produtos e serviços, com base na elaboração de um plano para tornar o negócio mais competitivo; • Princípio 2 – adoção de uma filosofia de trabalho moderna, não aceitando a convivência com atrasos, erros, materiais defeituosos e mão de obra inadequada; • Princípio 3 – eliminação da dependência da inspeção em massa, o foco deve ser na garantia da qualidade do processo; • Princípio 4 – consideração da qualidade ao selecionar fornecedores de produtos e serviços; • Princípio 5 – antecipação às consequências da falta da qualidade, através da identificação de problemas e de suas causas; • Princípio 6 – estabelecimento de métodos atualizados de treinamento no trabalho; • Princípio 7 – introdução de métodos de supervisão e criação de condições para realização adequada do trabalho; • Princípio 8 – criação de um clima de confiança e respeito mútuo, afastando o medo; • Princípio 9 – eliminação das barreiras entre departamentos e conhecimento das necessidades dos clientes; • Princípio 10 – eliminação das metas numéricas, cartazes e rótulos que apenas pedem maiores níveis de produtividade para os trabalhadores, sem indicar métodos ou ideias para atingi-los. O estabelecimento das metas deve ter clara indicação de como elas podem ser atingidas; • Princípio 11 – padrões de trabalho inconsistentes não devem ser impostos. Padrões numéricos devem ser utilizados como instrumentos para que todos tenham consciência de sua situação e do resultado de seus esforços; • Princípio 12 – estabelecimento de um programa de educação e treinamento para todos, a fim de afastar o medo e as barreiras que impedem que as pessoas se sintam responsáveis pelo seu trabalho; • Princípio 13 – manter a equipe atualizada em relação às mudanças de modelo, estilo, materiais, métodos e novas máquinas; • Princípio 14 – organizar a empresa de tal forma que os princípios operacionais anteriormente apresentados passem a orientar as decisões no dia a dia.
138 •
capítulo 5
Outra contribuição de Deming foi sua busca pelo controle efetivo dos processos. Para isso o autor destacou a necessidade de se estabilizar o processo por meio da eliminação dos fatores que afetam negativamente as características de qualidade desejadas e da identificação das causas comuns e especiais na variação destes processos (MOTTA; VASCONCELOS, 2002). Uma causa comum pode ser conceituada como uma variação natural de um processo, que, individualmente, contribuí pouco para a variação total do processo (MARTINS, 2002). Por ser inerente ao processo, a remoção das causas comuns requer mudanças na concepção e/ou na operação do processo, implicando em investimento na melhoria ou troca do processo (TOLEDO, 2000). Estudos revelam que as causas comuns representam por volta de 85% dos problemas existentes num processo, porém a remoção delas depende de uma ação da gerência sobre o sistema. Por exemplo, se uma máquina está desgastada e apresenta inúmeras folgas, somente uma decisão da alta gerência poderá trocá-la ou consertá-la (MARTINS, 2002). Já as causas especiais representam por volta de 15% dos problemas existentes num processo e a remoção delas pode ser feita no próprio local de trabalho por operários treinados ou por equipes de manutenção. Por exemplo, a troca de uma ferramenta desgastada pode ser detectada pelo próprio operário e ele mesmo poderá trocar a ferramenta gasta (MARTINS, 2002). Finalizando as contribuições de Deming, é importante destacar que ele foi criador do ciclo PDCA (Plan, Do, Check, Act), que é uma ferramenta da qualidade, voltada ao planejamento e gestão estratégica, utilizada para direcionar e priorizar os esforços de melhoria do desempenho em cada nível hierárquico, de forma que a empresa alcance seus objetivos estratégicos de longo e médio prazo (LEE; DALE, 1998). O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995): • Plan (planejar) – identificar os problemas-chave a partir de critérios analíticos e quantitativos, determinando como eles podem ser corrigidos; • Do (executar) – implementar o plano; • Check (verificar) – confirmar quantitativa e analiticamente se houve melhoria no desempenho e • Act (atuar) – atuar corretivamente caso o desempenho esteja fora do padrão determinado. Modificar, documentar e utilizar o processo adequadamente.
capítulo 5
• 139
5.3 Eras da Qualidade Garvin (1992) identificou quatro estágios da gestão da qualidade: • Controle do produto ou inspeção, • Controle do processo ou controle estatístico; • Garantia da qualidade; • Gestão estratégica da qualidade. Vamos aprender sobre cada um desses estágios? Controle do produto ou inspeção O controle do produto formalizou-se com a produção em massa e a necessidade de peças intercambiáveis, sendo executado através da criação de um sistema de medidas, gabaritos e acessórios, cujo foco principal era a verificação de erros (MAXIMIANO, 2006). A conformidade em relação ao padrão e a uniformidade dos produtos eram as preocupações primordiais, e não a resolução de problemas. Além disso, nesse período, a quantidade produzida de produtos era mais importante do que a qualidade, reforçando a mentalidade de praticar o controle para encontrar os defeitos ao invés de evitá-los (GARVIN, 1992). Havia empresas que preferiam arcar com os custos dos produtos deficientes, por acreditarem que esta atitude era mais barata do que tentar aprimorar a qualidade (RIBEIRO, 2003). Vale também comentar, que a ênfase na inspeção, mesmo que fosse mais barata não era capaz de atuar na causa verdadeira dos problemas! Controle estatístico ou do processo O controle do processo deu à qualidade um caráter científico através da utilização de técnicas estatísticas para verificar a uniformidade dos produtos (SILVA, 2002). A preocupação passa a ser o nível de variabilidade do processo e a inspeção passa a ocorrer por amostragem (MOTTA; VASCONCELOS, 2002). Com o crescimento das empresas e da expansão da produção em massa, tornou-se impraticável inspecionar a totalidade dos produtos, surgindo, assim o controle estatístico da qualidade (MAXIMIANO, 2006)
140 •
capítulo 5
Em lugar de se inspecionar todos os produtos, seleciona-se uma amostra de produtos para inspeção. O resultado da análise dessa amostra é estendido ao lote (GARVIN, 1992). Apenas como curiosidade, o pioneiro da aplicação da estatística ao controle da qualidade foi Walter A. Shewhart, dos Laboratórios Bell, que em 1924 preparou o primeiro rascunho do que viria a ser conhecido como carta ou gráfico de controle. (MAXIMIANO, 2006). Os gráficos de controle indicam o desempenho do processo, em termos de sua variação, mediante o controle estatístico de uma variável ou atributo relacionado a uma característica da qualidade do produto, subconjunto ou peça (SILVA, 2002). É importante observar que essa ferramenta funciona como um termômetro, ou seja, apenas indica o estado do processo. Não resolve o problema. É preciso diagnóstico e ação sistemática sobre o processo para que o problema seja efetivamente resolvido. Por isto, será imprescindível o conhecimento do processo que está sendo controlado (MARTINS, 2002). O Controle Estatístico de Processo (CEP) mede justamente o nível de variação desses duas componentes. A ideia é eliminar as causas especiais e deixar em um nível tolerável as causas comuns, de forma que esta variação não influencie de forma negativa a qualidade do produto ou serviço, aumentando a sensação de risco do consumidor (MARTINS, 2002). Quando somente causas comuns agem em um processo, ele apresentará um comportamento previsível, sendo possível prever seu comportamento. Isto implica que os parâmetros estimados para o processo são confiáveis uma vez que não existem causas especiais perturbando a variação natural do processo. Neste caso, é possível dizer que o processo está sob controle estatístico (MONTGOMERY, 1991). Os principais benefícios da utilização do CEP são (MONTGOMERY, 1991): • Controle da variação dos processos; • Redução do refugo e retrabalho com consequente diminuição dos custos; • Melhoria da qualidade de conformação; • Autocontrole por parte dos operadores dos processos (quem faz a “qualidade”); • Aumento da produtividade e motivação dos operadores dos processos; • Redução para o mínimo ou eliminação das necessidades de inspeção;
capítulo 5
• 141
• Possibilidade de sistematização das informações geradas nos gráficos de controle para futuros estudos de melhoria dos processos. Vale observar que o CEP não é a solução de todos os problemas de qualidade e produtividade de uma empresa, mas com certeza é parte de uma estratégia coordenada para a melhoria contínua do desempenho (MARTINS, 2002). O importante é exercer o controle de forma a avaliar os desvios com o pensamento probabilístico e não determinístico, ou seja, conhecendo a variação do processo, agir somente quando houver indícios de mudança brusca ou de tendência de mudança (WHEELER, 2001). Após verificar se um processo está sob controle estatístico, ou não, é possível analisar a capabilidade do processo, que demonstra, por meio de índices numéricos, quanto um processo é capaz de produzir um produto atendendo a dada especificação (MARTINS, 2002). De posse do índice de capabilidade de um processo é possível avaliar se ele irá satisfazer ou não as especificações de uma característica da qualidade (WHEELER, 2001). A análise de capabilidade é feita comparando-se a “voz do cliente”, expressa pelas especificações do produto, e a “voz do processo”, expressa pelas estimativas do parâmetro do processo (JURAN, GRYNA, 1991). Esta é parte fundamental do processo de melhoria da qualidade, uma vez que ela pode direcionar os esforços de melhoria no seguinte sentido (MARTINS, 2002): • Predizer quão bem um processo pode atender às exigências do cliente; • Auxiliar ou mesmo guiar engenheiros a escolherem um processo de produção; • Auxiliar no estabelecimento da frequência de amostragem do processo; • Especificar as necessidades de desempenho de um equipamento; • Auxiliar na seleção de fornecedores; • Auxiliar no projeto de tolerâncias; • Guiar o processo de redução da variação dos processos. Uma vez que o processo tem um índice de capabilidade que atende às exigências da empresa, então, os gráficos de controle poderão ser utilizados como uma ferramenta poderosa para controlar a qualidade dos processos (WHEELER, 2001).
142 •
capítulo 5
Garantia da Qualidade Na era da garantia da qualidade, o foco deixa de ser a fábrica e passa para o gerenciamento de todo o processo, da matéria-prima ao consumidor final, destacando-se a prevenção de problemas (GARVIN, 1992). Com essa nova dimensão, a qualidade deixa de ser atributo apenas do produto ou serviço. Deixa de ser também responsabilidade exclusiva do departamento da qualidade. A qualidade é problema de todos e envolve todos os aspectos da operação da empresa. A qualidade exige visão sistêmica, para integrar as ações das pessoas, as máquinas, informações e todos os outros recursos envolvidos na administração da qualidade. Esta ideia implica a existência de um sistema da qualidade (TOLEDO, 2000). A qualidade passa a ser vista de forma sistêmica e as empresas passam a exigir que os fornecedores assegurem a qualidade dos insumos (JURAN; GRYNA, 1991). Para colocar essa ideia em prática, as empresas compradoras passaram a fazer a auditoria do sistema da qualidade de seus fornecedores, em vez de fazer a inspeção de seus produtos no momento da entrega (MAXIMIANO, 2006). Os métodos de controle e melhoria da qualidade não ficam mais restritos à produção, pelo contrário, são estendidos a todas às áreas organizacionais (SHIBA et al, 1997). Para isso são utilizados os seguintes conhecimentos (GARVIN, 1992): • Custos da Qualidade – preocupação em identificar os custos evitáveis e os custos inevitáveis, eliminando os primeiros e reduzindo os segundos. Foco nos custos de prevenção, em detrimento dos custos de inspeção. • Controle Total da Qualidade (CTQ) – o controle da qualidade vai desde o projeto do produto/serviço até à entrega ao cliente, envolvendo todas as áreas funcionais, expandindo-se muitas vezes até os fornecedores. A principal preocupação é equilibrar custo e qualidade. • Engenharia da Confiabilidade – preocupação em garantir o desempenho do produto ao longo do tempo, de forma que este desempenhe sua função sem falhas. • Zero Defeito – filosofia que tem como foco a motivação e a conscientização sobre qualidade, dando menos ênfase a técnicas específicas de solução de problemas. O lema é fazer o trabalho certo da primeira vez.
capítulo 5
• 143
Gestão Estratégica da Qualidade Finalmente, a qualidade é elevada ao nível estratégico, transformando-se na base para enfrentar a concorrência (GARVIN, 1992). Dentro deste contexto, a qualidade adquire status de sistema de gestão, ligando-se aos objetivos estratégicos e tendo como foco a lucratividade da organização, através da melhoria contínua (SHIBA et al, 1997). Para expressar essa nova condição surge o termo Total Quality Management (TQM), Gestão pela Qualidade Total. Desde, então, a Gestão pela Qualidade Total, tornou-se uma “febre”, sendo adotada por muitas empresas, o que à primeira vista é bastante positivo. No entanto, infelizmente muitas organizações não foram bem sucedidas nessa empreitada, pois muitos consultores passaram a vender a ideia de que a TQM seria a panacéia para todos os males das organizações, a implantação do sistema seria fácil e os resultados seriam obtidos rapidamente. A atitude inconsequente desses profissionais levou muitos empresários a criarem um movimento de resistência em relação à adoção dos conceitos e métodos relacionados à TQM, impedindo as empresas de se tornarem mais competitivas (MARTINS, 1999).
5.4 A Qualidade num Projeto, segundo PMI Para que um projeto seja considerado bem sucedido, deverá haver uma correspondência entre o seu Escopo, Custo, Prazo e o nível de confiança nos seus produtos, ou seja, na sua qualidade. A qualidade, portanto, faz parte do trio de restrições encontradas em todos os projetos. É uma das vias para se chegar a um projeto bem-sucedido e, normalmente, determina se as expectativas dos stakeholders foram atendidas. Por exemplo, um projeto pode ser concluído rapidamente com investimento mínimo em gerenciamento da qualidade, contudo o nível de confiança no que ele produziu pode ter sido afetado, significativamente. O processo de Planejamento da Qualidade visa ao cumprimento de padrões de qualidade relevantes para o projeto em questão, elaborando, para tanto, um plano. O plano de Gerenciamento da Qualidade especifica como a política de qualidade será implementada pela equipe do projeto no decorrer das
144 •
capítulo 5
atividades. Assim, este processo é responsável por identificar e definir como fazer para obter a satisfação daquilo que o projeto considera como qualidade. Perceba que todo o conteúdo discutido neste capítulo será usado para ajudar a desenvolver o plano de gerenciamento da qualidade aplicada ao desenvolvimento de projetos.
5.4.1 Conceito de Qualidade O guia PMBOK conceitua Qualidade como: “a totalidade de características de uma entidade que a torna capaz de satisfazer necessidades declaradas ou implícitas”. Em outras palavras, para se ter qualidade, o produto ou serviço deverá atender aos seguintes critérios: • Adequação ao uso (o produto ou serviço pode ser usado?); • Adequação ao propósito (o produto ou serviço atende aos objetivos propostos?); • Satisfação do cliente (o produto ou serviço atende as expectativas do cliente?); • Conformidade com as especificações (o produto ou serviço está de acordo com os requisitos estabelecidos?).
5.4.2 Princípios Básicos Os princípios definidos para o gerenciamento da qualidade do projeto são basicamente os seguintes: • Satisfação do cliente – entender, gerenciar e influenciar necessidades de forma com que as expectativas do cliente sejam satisfeitas ou excedidas. Isto exige a combinação de conformidade com especificação (ou seja, o projeto deve produzir o que foi dito que produziria) e conveniência para o uso (o produto ou serviço produzido deve satisfazer às necessidades reais). • Prevenção ao invés de inspeção – o custo destinado a evitar erros é sempre muito menor que o custo para corrigi-los. • Responsabilidade do gerente – o sucesso exige a participação de todos os membros da equipe, mas permanece a responsabilidade do gerente em fornecer os recursos necessários para o êxito.
capítulo 5
• 145
5.4.3 Processo de Gerenciamento da Qualidade em Projetos Segundo PMBOK O gerenciamento da qualidade segundo PMI, fornece os métodos e ferramentas visando assegurar-se com que o projeto alcance seus objetivos de modo a satisfazer as necessidades para as quais ele foi empreendido. Este processo desempenha um papel importante no planejamento do projeto, e estabelece as principais funções do gerente, durante a fase de Execução das atividades do projeto. Os objetivos do gerenciamento da qualidade, neste caso, são: • Aumentar o grau de confiabilidade nos produtos gerados pelo projeto; • Reduzir o risco de falhas; e • Aproveitar as oportunidades de melhoria contínua. O Gerenciamento da Qualidade deve incorporar técnicas e ferramentas de controle de forma a garantir com que os produtos gerados apresentem as características para as quais foram concebidos. Esta parte do gerenciamento de projetos envolve também os processos para gerenciar mudanças, problemas e incidentes emergentes. O Gerenciamento da qualidade é realizado a partir de três estágios: • Planejamento da qualidade; • Controle da Qualidade; e • Ações corretivas
5.4.4 Planejamento da Qualidade O objetivo desta atividade é identificar quais padrões de qualidade são relevantes para o projeto e a forma de satisfazê-los. Elaborar o Plano da Qualidade pode exigir ajustes no custo ou no cronograma para incorporar as atividades de prevenção, além de análise detalhada de risco para problemas identificados pelo controle da qualidade. A elaboração do plano de gerenciamento da qualidade é responsabilidade do gerente do projeto. Os principais passos na elaboração do plano são: • Definição das características e atributos dos produtos gerados pelo projeto;
146 •
capítulo 5
• Definição das normas, padrões e procedimentos que serão usados para comparar as características esperadas dos produtos com as características efetivamente alcançadas durante a execução projeto; • Seleção de pontos de controle das características e elaboração das checklists bem como dos critérios pelos quais os produtos gerados serão aceitos ou rejeitados; • Comunicação aos envolvidos no projeto acerca dos mecanismos que serão adotados para assegurar a qualidade. É importante que os interessados sejam informados com relação à forma como a qualidade será alcançada. As habilidades e a experiência das pessoas que irão elaborar o plano da qualidade no projeto são fatores determinantes na efetividade deste processo. O plano da qualidade deve definir com clareza em que pontos as características dos produtos gerados pelo projeto serão medidas. Estes pontos são chamados de pontos de controle ou pontos de verificação. As fases do projeto devem ser estruturadas de forma a permitir com que as características dos produtos gerados sejam facilmente medidas e comparadas como o especificado.
5.5 Plano de Gerenciamento da Qualidade O plano da qualidade estabelece as políticas, responsabilidades e procedimentos que serão usados para assegurar um adequado nível de qualidade aos produtos ou serviços que devem ser seguidos por todos os participantes no projeto. Este documento resume o sistema de decisões e instruções com relação à garantia e ao controle da qualidade. A elaboração do plano da qualidade é baseada no entendimento das expectativas do cliente, esclarecidas nas fases iniciais do projeto. Na terminologia ISO 9000, o plano deve descrever o sistema de qualidade do projeto: “a estrutura organizacional, responsabilidades, procedimentos, processos e os recursos necessários para implementar a gerência da qualidade”. Além da Garantia de Qualidade e do Controle da Qualidade, o plano de Gerenciamento da Qualidade aborda também os critérios de aceitação dos produtos gerados pelo projeto.
capítulo 5
• 147
A equipe do projeto e os principais stakeholders estabelecem, previamente, os critérios para definir o aceite de cada produto ou serviço a ser entregue. No momento da entrega, os produtos ou serviços são avaliados com relação a estes critérios antes que sejam formalmente aprovados. É comum acordar que haja um documento para cada entrega principal, o qual necessite de aprovação e de um documento que defina os critérios da aceitação para o projeto como um todo. Os critérios de aceite variam de acordo com o que está sendo produzido. Ao criar um formulário de aceite, a equipe deve prever uma coluna para cada critério do aceite, uma coluna para expectativas do cliente, e uma outra para os resultados reais. Se a entrega atingir os critérios indicados, o cliente assina no campo apropriado, significando que ele aceita o produto e atesta conformidade com os requisitos. É essencial que o gerente e a equipe do projeto entendam claramente os requisitos e expectativas do cliente (usuário) com relação à qualidade do produto principal e dos produtos intermediários do projeto, ao preparar ou revisar o plano da qualidade.
5.6 O que usamos para elaborar o plano Política da qualidade: Uma declaração que descreve se a abordagem que a equipe do projeto irá adotar para garantir com que os produtos gerados pelo projeto estão em conformidade com as especificações. A equipe poderá adotar a política da qualidade da organização que conduz o projeto, ou formular uma política própria, caso não exista a política da empresa. Especificações – expectativas do cliente: A qualidade é baseada na percepção do cliente sobre os produtos gerados e como eles atendem às suas expectativas. A adequação dos produtos do projeto aos objetivos para os quais foram criados fornecem o seu nível de qualidade. A equipe do projeto deverá identificar e documentar (se necessário negociar) as expectativas (características, atributos) e assegurar com que a equipe e o cliente tenham entendimento comum sobre eles.
148 •
capítulo 5
Normas, padrões e procedimentos: As normas e os procedimentos relevantes para o projeto devem ser identificados e documentados. Isto inclui todas as regulamentações específicas da natureza do projeto em trabalho. Mecanismos devem ser colocados em prática para assegurar com que as normas e procedimentos sejam completamente atendidos pelos produtos gerados a partir do projeto. Outros procedimentos internos da empresa: Procedimentos internos podem ser considerados importantes para o planejamento da qualidade do projeto. Exemplos destes procedimentos podem ser os processos relativos ao gerenciamento do risco ou ao suprimento.
5.7 Controle da Qualidade As atividades de controle da qualidade são realizadas continuamente durante a execução do projeto, e em pontos definidos, para avaliar se o gerenciamento, e se os produtos ou serviços entregues atendem aos critérios de aceite, estabelecidos na fase de planejamento, além de identificar formas para eliminar causas de resultados insatisfatórios em decorrência do projeto. O controle da qualidade é, portanto, o processo contínuo de revisão e testes, realizado em pontos de controle pré-definidos onde o progresso e as características dos produtos gerados pelo projeto são examinados em detalhe. O controle da qualidade adequadamente aplicado faz com que a equipe do projeto seja mais eficaz, uma vez que previne situações nas quais o trabalho resulte em produtos que possam vir a ser rejeitados por não atenderem aos critérios estabelecidos. Neste caso, a equipe deve monitorar (medir) os resultados do projeto, e determinar se eles estão de acordo com os padrões de qualidade estabelecidos, além de identificar as formas para eliminar as causas de desempenhos insatisfatórios. Assim, a equipe identifica desvios e sugere ações corretivas para saná-los. Os métodos utilizados podem ser: • Teste dos produtos para determinar o nível de conformidade com as especificações; • Avaliação da satisfação dos stakeholders com os produtos do projeto;
capítulo 5
• 149
O patrocinador do projeto deve receber, regularmente, relatórios que resumam o andamento do controle da qualidade do projeto. Estes relatórios podem incluir dados estatísticos como, por exemplo, o número de não conformidades encontradas bem como ações corretivas tomadas.
ATIVIDADES 01. Qual a importância dos 14 princípios da qualidade, criados por Deming, para uma organização que deseja desenvolver um programa de qualidade? 02. Para que serve o ciclo PDCA? 03. Caracterize os quatro estágios da gestão da qualidade: controle do produto ou inspeção, controle do processo ou controle estatístico; garantia da qualidade; e gestão estratégica da qualidade. Aponte os pontos positivos e as limitações de cada um deles.
REFLEXÃO Chegamos ao final do nosso livro de Gestão da Qualidade em Projetos. Este último capítulo teve como tema principal, a abordagem do conceito de Qualidade, sua evolução e principais características. A ideia não foi esgotar o assunto, mesmo porque ele é bastante amplo e abrangente (sendo trabalhado na maioria dos cursos de graduação, em todas as áreas de conhecimento, profissão e segmento), mas sim mostrar sua importância para o sucesso gerenciamento de projetos nas organizações. Vimos que quanto maior for o projeto, mais importante se torna seu gerenciamento e acompanhamento de todas as etapas e áreas de conhecimento que o Gui PMBOK orienta. Esperamos que este conteúdo tenha sido compreendido e que ele de fato faça a diferença em seus estudos e na sua formação. Sucesso!
LEITURA Deming e os 14 princípios de qualidade Para você avançar nos conhecimentos sobre qualidade, recomendamos a leitura do texto abaixo, que é um resumo dos 14 princípios da qualidade postulados por Deming no livro Saia da Crise. No Brasil, este livro foi publicado pela Editora Futura em 2003.
150 •
capítulo 5
“Os 14 princípios da qualidade são a base para a transformação da indústria. Não basta resolver problemas, sejam eles grandes ou pequenos. Os 14 pontos aplicam-se a todos os tipos de organizações, grandes ou pequenas, de bens ou de serviços. Também se aplicam às divisões de uma empresa. A adoção e a prática desses 14 pontos indicam que uma empresa tem a intenção de sobreviver por muito tempo, protegendo os investidores e criando empregos. Há dois tipos de problemas para as empresas resolverem: (1) os problemas de hoje; e (2) os problemas do futuro. Os problemas de hoje incluem manutenção da qualidade dos bens produzidos, controle da produção (para que ela não seja muito maior do que as vendas previstas para o futuro imediato), orçamentos, empregos, lucros, vendas, serviços, relações públicas, estimativas e assim por diante. É muito fácil deixarmo-nos consumir pelos problemas do presente, tornando-nos cada vez mais eficientes na resolução deles, porém, negligenciando os problemas do futuro. Os problemas do futuro requerem, antes de mais nada, firmeza de propósito e dedicação no sentido de melhorar a qualidade dos produtos e dos serviços. Assim, a empresa fortalecerá sua posição competitiva, se firmará no mercado e criará novos empregos. Para isso no entanto, é fundamental que o presidente e a diretoria da empresa estejam comprometidas com as seguintes obrigações: • Inovar • locar recursos para o planejamento de longo prazo; • Oferecer serviços e produtos que contribuam para o bem-estar do consumidor; • Buscar novos insumos; • Melhorar os métodos de produção; • Investir em treinamento de pessoal. Não podemos mais tolerar os níveis normalmente aceitos de erros, defeitos, insumos inadequados, profissionais que não sabem o que devem fazer e que têm medo de perguntar, danos causados por manuseio impróprio de mercadorias, métodos antiquados de treinamento no ambiente de trabalho, supervisão inadequada e ineficaz, administradores descompromissados com a empresa. Não depender dos mecanismos de inspeção para garantir qualidade. Contar o tempo todo com mecanismos de inspeção para garantir qualidade equivale a contar com a incidência de defeitos e admitir que o processo de produção não está à altura das especificações. A inspeção vem tarde demais, os defeitos já estão lá. Além disso, é ineficaz e dispendiosa. Quando um produto transpõe os portões de uma fábrica, já é tarde demais para fazer alguma coisa acerca de sua qualidade. A qualidade não vem da inspeção, mas do aperfeiçoamento
capítulo 5
• 151
do processo de produção. Inspeção, retrabalho, degradação e sucateamento de produtos não constituem medidas de correção do processo de produção. O retrabalho custa dinheiro. É importante que a inspeção seja feita no momento exato para que o custo total seja minimizado. É preciso também abandonar a prática de escolher fornecedores com base apenas no preço. Não podemos mais abrir mão da qualidade dos produtos e serviços exclusividade aos sabores da competição por preços mais baixos – não nos dias de hoje, quando a demanda por uniformidade e confiabilidade é maior do nunca. Preços não significam nada sem uma medida exata da qualidade daquilo que é comprado. Na ausência de medidas de qualidade adequadas, as concorrências são vencidas pelas ofertas de preço menor e o resultado inevitável disso é qualidade inferior e custos altos. Os departamentos de compra das organizações devem mudar de enfoque e considerar, em vez do custo inicial mais baixo, o custo total mais baixo dos materiais a ser comprados. Isso requer preparo. Também é preciso compreender que as especificações que acompanham os produtos à venda não contam toda a história a respeito do desempenho desses produtos. Materiais e componentes podem funcionar muito bem isoladamente, mas apresentar problemas quando agregados na linha de produção ou no produto final. Portanto, é preciso observar uma amostra desses materiais ao longo de todo o processo e avaliar seu desempenho, tanto na montagem de estruturas complexas quanto junto ao consumidor. Um relacionamento de longo prazo entre compradores e fornecedores é essencial para a obtenção de economia. Há vantagens operacionais nessa parceria. Muito embora dois fornecedores produzam materiais de excelente qualidade, sempre haverá diferenças. Todos os profissionais de produção sabem que a troca de fornecedores implica em perda de tempo. Esse tempo pode ser de apenas 15 minutos. Ou pode ser de oito horas numa mineradora. Ou pode ser de semanas. As variações entre os lotes de um único fornecedor são suficientes para causar problemas na produção. Não é difícil supor que as variações entre os lotes de diferentes fornecedores causem problemas ainda maiores”. Fonte: Adaptado: DEMING, W. E. Saia da crise. São Paulo: Editora Futura, 2003.
REFERÊNCIAS BIBLIOGRÁFICAS ABNT. NBR ISO 9000: 2000. ATTADIA, L.; MARTINS, R. Medição de desempenho como base para a evolução da melhoria contínua. Revista Produção, ABEPRO, v.13, n.2, pp. 33-41. 2003. BESSANT, J., CAFFYN, S; GALLAGHER, M. An evolucionary model of continous improvement behaviour. Technovation. March, 2000.
152 •
capítulo 5
BESSANT, J.; CAFFYN, S.; GILBERT, J.; HARDING R & WEBB, S. Rediscovering continous improvement. Technovation. v. 14. n.1, 1994. CARAVANTES, G.; PANNO, C.; KLOECKNER, M. Administração: teorias e processo. São Paulo: Pearson Prentice Hall, 2005. CARONA, N. Os prêmios de excelência da qualidade brasileiro e europeu. Anais. V SIMPOI. São Paulo: FGV-EAESP, 2002. CARVALHO, M. M et. al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005. DEMING, W. E. Saia da crise. São Paulo: Editora Futura, 2003. FQN. Critérios de Excelência. Fundação Nacional da Qualidade (FQN). Disponível em http://www. fnq.org.br. Acesso em: 01/05/ 2008. GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. Rio de Janeiro: Qualitymark, 1992. GRONROOS, C.: Marketing: gerenciamento e serviços. 13. ed. Rio de Janeiro: Campus, 1993. JURAN, J. M; GRYNA, F. M. Controle da qualidade: handbook. São Paulo: Makron Books, 1991. (vol.6) JURAN, J. M. Mangerial breakthrough. New York: McGrawHill, 1995. KANO. N. A perspective on quality activities in american firms. In: COLE, R. E. (ed.) The death and life of american quality movement. New York, Oxford University Press, 1995, p. 215-235. LACOMBE, F.; HEILBORN, G. Administração: princípios e tendências. São Paulo: Saraiva, 2003. LEE, R.; DALE, B. Policy Deployment: an examination of the theory. International Journal of Quality. MCB University Press, v.15, n. 5. 1998. LIMA, S.A.; MARTINS, M. F. A gestão da qualidade na indústria de calçados de Franca-SP. V SIMPOI (Simpósio de Administração da Produção, Logística e Operações Internacionais). Anais. ISSN 15186539. São Paulo: FGV- EASP, 2002. MARTINS, R. Controle Estatístico de Processo. Material didático da Disciplina Estatística Industrial e Controle da Qualidade. Curso de Graduação em Engenharia de Produção: UFSCar, 2002. MARTINS, R. Modelo para avaliação da evolução da gestão da qualidade em empresas industriais: proposta e Aplicação em Pequenas e Médias Empresas Industriais da Cidade de São Carlos. Dissertação de mestrado apresentada ao Programa de pós Graduação em Engenharia de Produção da UFSCar. 1999. MARTINS, R.; TOLEDO, J. Proposta de modelo para elaboração de programas de gestão para a qualidade total. Revista de Administração, São Paulo v.33, n.2, pp.52-59, abril/junho 1998. MAXIMIANO, A. Teoria geral da administração: da revolução urbana à revolução digital. 6. ed. São Paulo: Atlas, 2006. MERLI, G. The tqm approach to capturing global markets. Ifs, uk, 1993.
capítulo 5
• 153
MORAES, E. uma análise crítica sobre o impacto dos fundamentos nos critérios de excelência do PNQ. Anais. V SIMPOI. São Paulo: FGV-EAESP, 2002. MONTGOMERY, D. C. Statistical quality control. 2. ed. New York, John Wiley & Sons, 1991. MOTTA, F.; VASCONCELOS, I. Teoria Geral da Administração. São Paulo: Pioneira Thompson Learning, 2002. RIBEIRO, A. Teorias da Administração. São Paulo: Saraiva, 2003. ROBLES JR, A. Custos da Qualidade: uma estratégia para a competição global. São Paulo: Atlas, 1994. SAVOLAINEN, T. Cycles of continuous improvement: realizing competitive advantages through quality. International Journal of Operations & Production Management. v. 19. n.11, 1999. SHIBA, S. et al. A new american tqm. Capítulos 1 e 2. Editora Productivy. 1993. SHIBA, S. ET. al. Introduction to hoshin management. Center for Quality of Management Journal. v.4. n.3 Fall, 1995. SHIBA, S et al.. TQM: quatro revoluções na gestão da qualidade. Artes Médicas. Porto Alegre: 1997. SILVA, R. Teorias da Administração. São Paulo: Pioneira Thompson Learning, 2002. SLACK, N. et. Al. Administração da Produção. Editora Atlas, 1997. TOLEDO, J. C. Enfoque dos principais autores para a gestão da qualidade. Apostila da Disciplina Planejamento e Gestão da Qualidade do Departamento de Engenharia de Produção da Universidade Federal de São Carlos. 2000. TOLEDO, J. C; CARPINETTI, L. C. Gestão da Qualidade. Capítulo13. Fábrica do Futuro, NUMA, Editora Banas. 2000.
GABARITO Capítulo 1 01. Sim, é possível e recomendado. Uma vez que um processo sistematizado seja seguido e ganhe maturidade, resultados de sucessos conseguidos em um determinado projeto poderão ser reproduzidos em outros projetos que sigam o mesmo processo de gestão. Lógico que o ideal é termos pessoas sensacionais trabalhando em processos sistematizados, "repetíveis" e maduros. Contudo, apenas pessoas sensacionais não garantem que um sucesso de agora possa ser repetido em outros projetos, mesmo com as mesmas pessoas 02. PMI é uma instituição sem fins lucrativos cujas siglas representam Project Management Institute que tem por objetivo estabelecer o estado da arte de gestão de projetos e também a profissionalização da gestão do projeto no mundo.
154 •
capítulo 5
03. Certificação O PMI oferece seis certificações que atestam conhecimento e competência, dentre as quais, a de Profissional em Gerenciamento de Projetos (PMP)®, que conta com mais de 370.000 profissionais certificados em todo mundo. Os salários e oportunidades de carreiras dos profissionais certificados demonstram que os empregadores reconhecem o valor agregado por aqueles que possuem essas certificações. Padrões Globais Os 12 padrões para gerenciamento projetos, programa e de portfolio do PMI são os padrões com mais alto reconhecimento na profissão – e que, cada vez mais, vêm se tornando o modelo para o gerenciamento de projetos em empresas e governos. Esses padrões são desenvolvidos pelos milhares de voluntários qualificados e atualizados do PMI, com experiência em todos os tipos de projetos, e estabelecem uma linguagem comum para o gerenciamento de projetos em todo o mundo. Treinamento e Educação O PMI oferece uma ampla gama de oportunidades de desenvolvimento profissional, desde nossos SeminarsWorld® e cursos de ensino a distância (e-learning) para congressos mundiais e outros eventos do PMI. Você também pode se dirigir a um dos mais de 1400 Provedores Registrados de Educação (REPs) para formação e desenvolvimento continuado em gerenciamento de projetos. Aqueles que estudam em instituições de ensino superior podem contar com os mais de 60 programas de graduação e pós-graduação já reconhecidos pelo Centro de Acreditação Global do PMI para Programas de Educação em Gerenciamento de Projetos. Pesquisa O Programa de Pesquisa do PMI, o mais extenso na área, promove a ciência, a prática e a profissão de gerenciamento de projetos. O Programa promove o conhecimento em gerenciamento por meio de projetos de pesquisa, simpósios e pesquisas, divulgando essas informações através de publicações, conferências de pesquisa e sessões de trabalho. 04. ( P ) Ações para o desfile de carnaval de um determinado ano. ( TO ) Construção de carros em série em uma linha de b) montagem. ( P ) Ações para a criação de um novo modelo de carro de uma determinada montadora. ( P ) Desenvolvimento de um novo d) software de ERP para uma determinada empresa. ( TO ) Ações do setor de RH para a emissão de pagamentos dos funcionários de uma determinada empresa.
capítulo 5
• 155
( P ) Ações de uma empresa para determinar o processo de emissão de pagamentos dos funcionários de uma determinada empresa. ( TO ) Tarefas associadas a um funcionário de uma lanchonete para a confecção de lanches padrões desta lanchonete.
Capítulo 2 01. • Gerenciamento/Gestão de integração do projeto: A Gerência da integração do projeto é o núcleo do gerenciamento de projetos, e é composto dos processos do dia a dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo contínuo que o gerente executa para garantir que o projeto prossiga do início ao fim. • Gerenciamento/Gestão do escopo do projeto: Gerenciamento do Escopo é composto dos processos para garantir que o projeto inclua todo o trabalho exigido, e somente o trabalho exigido, para completar o projeto com sucesso. • Gerenciamento/Gestão de tempo do projeto: O objetivo da gerência do tempo de projeto é descrever os processos requeridos para o término do projeto, garantindo que o mesmo cumpra com os prazos definidos em um cronograma de atividades. • Gerenciamento/Gestão de custos do projeto: A gerência do custo do projeto agrega os processos que envolvem planejamento, estimativa, orçamento e controle de custos que serão necessários para a conclusão do projeto a partir de uma previsão orçamentária. • Gerenciamento/Gestão da qualidade do projeto: Originalmente, tal função era relativa e voltada para a inspeção; hoje, as atividades relacionadas com a qualidade ampliaram-se bastante e são consideradas essenciais para o sucesso estratégico do projeto. • Gerenciamento/Gestão de recursos humanos do projeto: Gerenciamento de recursos humanos do projeto tem como base a identificação e documentação de funções, responsabilidades e relações hierárquicas do projeto em relação aos recursos humanos envolvidos, além da criação do plano de gerenciamento de pessoal. Obtenção dos recursos humanos necessários para terminar o projeto. • Gerenciamento/Gestão das comunicações do projeto: Inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. Os gerentes de projetos gastam a maior parte do seu tempo se comunicando com os membros da equipe e outras partes interessadas do projeto, quer sejam internas (em todos os níveis da organização) ou externas à organização.
156 •
capítulo 5
• Gerenciamento/Gestão de riscos do projeto: Os Riscos de projeto são um conjunto de eventos que podem ocorrer sob a forma de ameaças ou de oportunidades que, caso se concretizem, influenciam o objetivo do projeto, negativamente ou positivamente. • Gerenciamento/Gestão de aquisições do projeto: O Gerenciamento de Aquisições do Projeto é responsável por cuidar das compras e aquisições de produtos, serviços ou resultados necessários para a realização do trabalho. A organização pode ser o comprador ou fornecedor do produto, serviço ou resultado. • Gerenciamento das Partes Interessadas do Projeto: O gerenciamento das partes envolvidas do projeto concentra-se em um dos elementos mais importantes da gestão de projetos, e gerencia os interessados, suas expectativas, e compromissos. 02. As fases do ciclo de vida de gerenciamento de projetos se interagem intensamente. Então, podemos dizer que os processos que compõem essas fases também estão se interagindo intensamente. A coordenação da interação desses processos é de responsabilidade da gerência de integração, uma vez que é nessa área de conhecimento que se decide como cada área será planejada. Ex.: A gerência de integração é quem irá compor o plano de gerenciamento do projeto que irá definir e coordenar todos os planos de gerenciamento auxiliares das outras áreas de conhecimento, inclusive das áreas de gerenciamento de custo, tempo e risco, conforme citado no exemplo anterior. Por isso, voltamos a dizer que a gerência de integração é responsável pela integração dos processos entre os grupos de processos (fases) do ciclo de vida de gerenciamento de projetos para realizar os objetivos do projeto dentro dos procedimentos definidos da organização. 03. O gerenciamento de escopo trata dos limites do projeto, estabelecendo tudo o que está dentro do projeto e tudo o que está fora do projeto (às vezes, especificar o que está fora é quase tão importante do que especificar o que está dentro, por causa dos requisitos de contexto e requisitos não funcionais dos softwares). Definir corretamente o escopo é uma das partes mais importantes do gerenciamento de projeto, pois se pensarmos em qualidade como um conceito relacionado com o atendimento dos requisitos dos stakeholder, então determinar muito bem esses requisitos é o primeiro passo para entregar um produto/serviço de qualidade e ter sucesso no projeto. 04. Na fase de definição de escopo, temos a etapa de preparação de uma declaração de escopo detalhada para o projeto. Ela envolve a identificação de qual o trabalho a ser realizado e os responsáveis, o dimensionamento dos pacotes de trabalho, ou work packages (WP) e a criação de um dicionário que explique os aspectos técnicos da EAP. 05. A EAP é a estrutura analítica do projeto. Embora em um primeiro momento o nome em português desta ferramenta possa parecer estranho, quando analisamos o nome em inglês fica mais fácil entender qual é a proposta desta ferramenta.
capítulo 5
• 157
WBS é o termo em inglês referente a EAP e significa work breakdown structure, que quer dizer: Work: esforço físico ou mental sustentável para transpor obstáculos e atingir um objetivo; Breakdown: divisão em partes ou categorias. Decompor em partes menores; Structure: algo organizado de forma padronizada ou formalizada.
Assim fica mais fácil de entender que a EAP e a decomposição (breakdown) hierárquica (structure) orientada a entrega do trabalho (work) do escopo do projeto. Esses trabalhos devem ser executados pela equipe do projeto para atingir os objetivos do projeto. A decomposição dos trabalhos em partes menores serve para torná-los mais gerenciáveis. A EAP é uma ferramenta gráfica, então a decomposição hierárquica do trabalho do projeto acontece por meio de retângulos e interligações desses retângulos para formar a hierarquia de trabalho. 06. É a técnica de decomposição do trabalho, que sugere a subdivisão das entregas de trabalhos em componentes menores e mais facilmente gerenciáveis de forma que, em processos futuros do ciclo de vida de gerenciamento de projetos, o tempo e o custo possam ser estimados de forma confiável. O nível mais baixo da EAP. Cada pacote de trabalho deve buscar atender às seguintes características: • Pode ser estimado de forma realista e confiável; • Não permite uma nova subdivisão lógica; • Pode ser concluído “rapidamente”; • Sua execução pode ser atribuída a uma pessoa ou grupo de pessoas (internos ou externos) • Possui um término significativo, produzindo uma entrega 07. A definição de escopo envolve a preparação de uma declaração de escopo detalhada para o projeto, que envolve a identificação de qual o trabalho a ser realizado e os responsáveis, o dimensionamento dos pacotes de trabalho, ou work packages (WP) e a criação de um dicionário que explique os aspectos técnicos da EAP. Entre os aspectos positivos da definição de escopo estão: • obriga os stakeholders a concordarem com as fronteiras do projeto; • durante a execução, permite identificar as mudanças que estão fora do escopo do projeto e requerem renegociação do contrato original; • ajuda a estabelecer critérios que mensurem o sucesso do projeto, • de forma que todos os envolvidos os conheçam e estejam de acordo; • auxilia a compreensão da equipe de projeto sobre as abordagens e métodos utilizados no projeto.
158 •
capítulo 5
08. Premissas ou suposições são fatores que, para os propósitos do planejamento, são consideradas verdadeiros, reais, ou certos. As premissas afetam todos os aspectos do planejamento do projeto e são parte da elaboração progressiva do projeto. As equipes de projetos freqüentemente identificam, documentam e validam premissas como parte de seu processo de planejamento. Por exemplo, se a data na qual uma pessoa chave estará disponível para o projeto é incerta, a equipe pode assumir uma data de início específica. Podem ser organizacionais, ambientais e externas. Podem ser consideradas como as “cláusulas contratuais” que se não forem cumpridas, comprometem o sucesso do projeto, ou aquilo que você quer exigir das partes interessadas. Por exemplo: Disponibilidade de 50% do tempo do cliente durante os testes. Se o cliente não estiver disponível 50% do tempo, o prazo, provavelmente, não será cumprido.
Capítulo 3 01. Atrasos na conclusão comprometem o custo, retardam a entrega e consequentemente, a disponibilidade de iniciar a utilização dos mesmos e/ou entrarem em operação. Atrasos podem causar também em quebras de cláusulas contratuais e consequente falha do projeto. Dessa forma, o gerenciamento do tempo se mostra um processo muito importante para que o projeto seja bem sucedido. 02. Definição de atividades, sequenciamento de atividades, estimativa das durações das atividades, desenvolvimento do cronograma, controle do cronograma. 03. Lista de atividades. A lista de atividades deve incluir todas as atividades que serão realizadas no projeto. Deve ser organizada como um extensão da EAP para assegurar que esta está completa e que não inclui qualquer atividade que não seja requerida como parte do escopo do projeto. Assim como na EAP, a lista de atividades deve incluir descrições de cada atividade para garantir que os membros da equipe do projeto entenderão como o trabalho será feito. Detalhamento do suporte; Os detalhes de suporte referentes à lista de atividades devem ser documentados e organizados de forma a facilitar seu uso por outros processos da gerência do projeto. Os detalhes de suporte devem sempre incluir a documentação de todas as premissas e restrições identificadas A quantidade de detalhes adicionais varia de acordo com a área de aplicação. Atualizações na EAP. Ao utilizar a EAP para identificar quais atividades são necessárias, a equipe do projeto pode identificar a falta de algum subproduto ou pode ainda determinar que a descrição dos subprodutos precisa ser clareada ou corrigida. Qualquer uma destas atualizações deve ser refletida na EAP e na respectiva documentação, como por exemplo a estimativa dos custos. Estas atualizações são muitas vezes chamadas de refinamentos (re-
capítulo 5
• 159
finements) e ocorrem mais frequentemente quando o projeto envolve uma tecnologia nova ou em desenvolvimento. 04. Estimar tempo em atividades planejadas é algo complexo em qualquer área, mas na área de TI esta atividade é um pouco mais complicada pela característica abstrata das tarefas e seu cunho intelectual, em alguns casos quase “artísticos” (por exemplo o desenvolvimento de um software científico como processamento de imagem ou biotecnologia). Por isso, é comum esse processo de estimativa de tempo das atividades seja realizado por pessoas que estão mais acostumadas com o contexto e natureza do projeto (e que utilizam a experiência delas para realizar estimativas mais confiáveis) e também é realizado em caráter progressivo, à medida que as informações necessárias para as estimativas vão ficando cada vez mais claras. Mas, não só a “arte” e a experiência ou conhecimento tácito dos colaboradores são alternativas para este processo. Há técnicas sistematizadas como pontos por função e pontos de caso de uso que podem ser utilizadas juntamente com bases históricas para a determinação de estimativas de tamanho de software. 05. Gráfico de Gantt Método do caminho crítico – por meio dessa técnica é possível descobrir em um gráfico de redes qual é o caminho de atividades mais longo que será feito no projeto e aquele que terminará mais cedo. Com essa análise é possível gerenciar o tempo de entrega do projeto aplicando então técnicas de paralelismo e compressão às atividades do caminho mais longo, ou seja, o caminho crítico do projeto! Aplicação de antecipações e esperas – durante o sequenciamento das tarefas antecipações e atrasos podem ocorrer e nesta técnica eles são ajustados. Compressão do cronograma – técnicas para a redução do cronograma sem reduzir o escopo do projeto: são analisadas as compensações entre custo e cronograma em busca da redução do tempo de execução de uma dada atividade. Paralelismo – descobrir no grafo de rede de atividades as atividades que estão seriadas e tentar a execução das mesmas em paralelo para reduzir o tempo do caminho crítico. Gráfico de Milestones Baseline
160 •
capítulo 5
06.
Executar 1o Passo Desenhar: Etapa inicial do projeto e as atividades sem dependência (A, D, G, I) Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H I
E, G, I -
J
I
K
A D G
I
H, J
Não complete o arco enquanto não tiver clarificado as dependências
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
A
B E
D G
I
capítulo 5
• 161
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
A D G
I
Convergir na mesma etapa com A e D para iniciar B e E (atenção que A e D começam na mesma etapa...)
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I
162 •
J
I
K
H, J
capítulo 5
A
B E
D
F
G I
H J
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
B
A E
D G
I
Juntar E, G, I para iniciar F e H (atenção que J só depende de I ...)
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
A
B E
D
F
G I
H J
Junte B e F para iniciar C; Idem com H e J para iniciar K
capítulo 5
• 163
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
A
B C
E
D
F
G
H
I
K
J
Passos Seguintes Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas? Atividade Depedência A B C D E F G
A, D B, F A, D E, G, I -
H
E, G, I -
I J
I
K
H, J
A
B C
E
D
F
G I
H J
K
Todas as atividades desenhadas. Não há dependência de C e K que estas convergem na Etapa Final do Projeto
07. Análise de variação. A execução do processo da análise de variação durante a monitoração do cronograma é o elemento chave para o controle do tempo. A comparação das datas alvos com as realizadas de início e fim, nos fornece informações úteis para a detecção de desvios e para a implementação de ações corretivas em caso de atraso. As etapas comuns são: Verificar qualidade das informações coletadas; Determinar variações entre real x linha de base; Determinar impacto das variações nos custos e no cronograma;
164 •
capítulo 5
Analisar tendências das variações e documentar quaisquer descobertas sobre fontes de variação e área de impacto.
Capítulo 4 01. A análise quantitativa de riscos mensura números e dados tangíveis do projeto, já a análise qualitativa, envolve subjetividade dos sujeitos envolvidos, que terão percepção distintas quanto a qualidade do projeto e seus desmembramentos. 02. Gerenciamento de riscos possibilita a chance de melhor compreender a natureza do projeto, envolvendo os membros do time de modo a identificar as potenciais forças e riscos do projeto e responder a eles, geralmente associados a tempo, qualidade e custos. Portanto, a sobrevivência de qualquer empreendimento, atualmente, está intimamente vinculada ao conceito de aproveitar uma oportunidade, dentro de um espectro de incertezas. O que torna a gestão dos riscos se tornar tão importante são fatores diversos, como o aumento da competitividade, o avanço tecnológico e as condições econômicas, que fazem com que os riscos assumam proporções muitas vezes incontroláveis. 03. Um efetivo processo de comunicação é necessário para garantir que todas as informações desejadas cheguem às pessoas corretas no tempo certo e de uma maneira economicamente viável. Sempre que pensamos em gerenciamento de projetos, logo, pensamos em administração de tempo, escopo e qualidade, na verdade, a administração de todas estas áreas requer do gerente de projeto uma gama de habilidades e técnicas efetivas, pois muitos elementos precisam ser coordenados. Manter um time unido e sólido, e atender as expectativas dos stakeholders é um dos grandes desafios que um gerente de projeto enfrenta. Um bom plano de comunicação pode ser chave para que a execução e o controle do projeto tenham sucesso. Portanto, é responsabilidade desta área de conhecimento fornecer as ligações entre pessoas e informações adequadas, sendo que entenderemos como pessoas todos os stakeholders do projeto, como partes interessadas, cliente e patrocinador. 04. Stakedolders de um projeto: acionistas da organização, diretoria, clientes, colaboradores, fornecedores de produtos e serviços, comunidade em que a organização esteja inserida etc.
Capítulo 5 01. Tais princípios são ferramentas norteadoras para um eficaz monitoramento de um projeto, seu eficaz desenvolvimento e efetividade nas respostas. Com base nos princípios da
capítulo 5
• 165
qualidade, segundo Deming é possível o acompanhamento de qualquer projeto ou processo, de modo que ele venha atender aos objetivos propostos. 02. Trata-se de uma ferramenta da qualidade, voltada ao planejamento e gestão estratégica, utilizada para direcionar e priorizar os esforços de melhoria do desempenho em cada nível hierárquico, de forma que a empresa alcance seus objetivos estratégicos de longo e médio prazo (LEE; DALE, 1998). O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995): • Plan (planejar) – identificar os problemas-chave a partir de critérios analíticos e quantitativos, determinando como eles podem ser corrigidos; • Do (executar) – implementar o plano; • Check (verificar) – confirmar quantitativa e analiticamente se houve melhoria no desempenho e • Act (atuar) – atuar corretivamente caso o desempenho esteja fora do padrão determinado. Modificar, documentar e utilizar o processo adequadamente. 03. Controle do produto ou inspeção O controle do produto formalizou-se com a produção em massa e a necessidade de peças intercambiáveis, sendo executado através da criação de um sistema de medidas, gabaritos e acessórios, cujo foco principal era a verificação de erros (MAXIMIANO, 2006). A conformidade em relação ao padrão e a uniformidade dos produtos eram as preocupações primordiais, e não a resolução de problemas. Além disso, nesse período, a quantidade produzida de produtos era mais importante do que a qualidade, reforçando a mentalidade de praticar o controle para encontrar os defeitos ao invés de evitá-los (GARVIN, 1992). Controle estatístico ou do processo O controle do processo deu à qualidade um caráter científico através da utilização de técnicas estatísticas para verificar a uniformidade dos produtos (SILVA, 2002). A preocupação passa a ser o nível de variabilidade do processo e a inspeção passa a ocorrer por amostragem (MOTTA; VASCONCELOS, 2002). Com o crescimento das empresas e da expansão da produção em massa, tornou-se impraticável inspecionar a totalidade dos produtos, surgindo, assim o controle estatístico da qualidade (MAXIMIANO, 2006). Garantia da Qualidade Na era da garantia da qualidade, o foco deixa de ser a fábrica e passa para o gerenciamento de todo o processo, da matéria-prima ao consumidor final, destacando-se a prevenção de problemas (GARVIN, 1992). Com essa nova dimensão, a qualidade deixa de ser atributo ape-
166 •
capítulo 5
nas do produto ou serviço. Deixa de ser também responsabilidade exclusiva do departamento da qualidade. A qualidade é problema de todos e envolve todos os aspectos da operação da empresa. A qualidade exige visão sistêmica, para integrar as ações das pessoas, as máquinas, informações e todos os outros recursos envolvidos na administração da qualidade. Esta ideia implica a existência de um sistema da qualidade (TOLEDO, 2000). Gestão Estratégica da Qualidade Nesta fase, a qualidade é elevada ao nível estratégico, transformando-se na base para enfrentar a concorrência (GARVIN, 1992). Dentro deste contexto, a qualidade adquire status de sistema de gestão, ligando-se aos objetivos estratégicos e tendo como foco a lucratividade da organização, através da melhoria contínua (SHIBA et al, 1997).
capítulo 5
• 167
168 •
capítulo 5