Fundamentos em Gerenciamento de Projetos

ANDR BERNaRDO DE OLIVEIRa REN CHIaRI
FUNDAMENTOS EM
PROJETOS
PMBOK 5 EDIO
A
GERENCIAMENTO DE
BASEADO NO
2|
ndice
Captulo 1 Introduo A histria do Gerenciamento de Projetos e o cenrio atual no mundo........................................................ 4 Quem o PMI?......................................................................... 5
Padres Globais (Standard).......................................................................5 Certificaes..............................................................................................6 Captulos e Comunidades de Prticas.......................................................8 Pesquisas...................................................................................................9
Captulo 2 Conceitos Bsicos de Gerenciamento de Projetos O que um Projeto?.................................................................. 10 De onde surgem os projetos?.................................................... 11 O que Gerenciamento de Projetos?......................................... 12 Gerente de Projetos, o Maestro de um Projeto........................... 13 Competncias em Gerenciamento de Projetos.......................... 14 O que um Programa?.............................................................. 16 O que um Portfolio?................................................................ 17 O que Patrocinador (Sponsor)?............................................... 18 O que Parte Interessada (Stakeholder)?.................................. 19 Equipe do Projeto X Equipe de Gerenciamento do Projeto.......... 19 Escritrio de Gerenciamento de Projetos EGP (Project Management Office PMO)................................... 20 Tipos de Organizao................................................................ 21 tica e Responsabilidade Profissional....................................... 24 O Ciclo de Vida.......................................................................... 24
Ciclo de Vida do Projeto.............................................................................24 Ciclo de Vida do Produto...........................................................................25 Processo de Gerenciamento de Projetos..................................................25
FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO
3|
Captulo 3 Processos de Gerenciamento de Projetos Viso Geral................................................................................ 28 Grupos de Processos................................................................ 28

Entradas, Tcnicas e Ferramentas, e Sadas............................................29
reas de Conhecimento..................................................... 30
Gerenciamento da Integrao do Projeto..................................................31 Gerenciamento do Escopo do Projeto.......................................................31 Gerenciamento do Tempo do Projeto........................................................31 Gerenciamento dos Custos do Projeto......................................................31 Gerenciamento da Qualidade do Projeto...................................................32 Gerenciamento dos Recursos Humanos do Projeto..................................32 Gerenciamento da Comunicao do Projeto.............................................32 Gerenciamento dos Riscos do Projeto.......................................................32 Gerenciamento das Aquisies do Projeto................................................33 Gerenciamento das Partes Interessadas do Projeto.................................33
Captulo 4 Aplicando as Boas Prticas de Gerenciamento de Projetos
Estudo de Caso: a Empresa SOCIALLY............................... 34

Iniciando o Projeto.....................................................................................34 Planejando o Projeto..................................................................................40 Executando o Projeto.................................................................................56 Monitorando e Controlando o Projeto........................................................60 Encerrando o Projeto.................................................................................63
Sobre a COMMUNIT............................................................ 65
4|
CAPTULO 1
Captulo 1 Introduo
A histria do Gerenciamento de Projetos e o cenrio atual no mundo

Ao longo do tempo, o gerenciamento de projetos teve um papel importante na histria da civilizao. Por mais incrvel que parea, o gerenciamento de projetos anterior construo das pirmides. Olhando para a construo da Grande Pirmide de Quops sob a tica do gerenciamento de projetos, podemos identificar muitos obstculos. A fora de trabalho foi o problema mais bvio, seguido pela originalidade das cmaras do rei, que foram construdas com granito extrado h mais de 400 quilmetros de distncia. A Grande Pirmide levou cerca de vinte anos para ser concluda e empregou 10.000 pessoas. Usando ferramentas primitivas feitas de cobre, os homens cortavam enormes blocos de pedra a um centmetro por hora. Na era medieval, o Reino Unido trouxe um novo contexto para o papel de gerente de projeto, que na poca era desempenhado por trabalhadores da construo civil. Os gerentes de projeto daquela poca tinham que saber como garantir a segurana das fortalezas, atravs de elementos arquitetnicos que pudessem dificultar ou impedir a entrada de invasores. Dentre as construes, havia escadarias em sentido horrio que obrigavam o invasor a usar a espada com a mo esquerda, ou portas mais baixas no topo das escadas que foravam o invasor a abaixar a cabea para entrar, ficando assim vulnervel a um ataque. J no sculo 19, durante a primeira revoluo industrial, os projetos de construo eram considerados como arte, tornando-se um pouco mais importantes quando as fbricas precisavam de grandes espaos para alocar trabalhadores, produtos e maquinrio. Durante este tempo, enquanto a tecnologia avanava rapidamente, as ferramentas para projetos permaneciam praticamente as mesmas. A necessidade de um responsvel por organizar e assumir o controle dos projetos fez surgir os supervisores de projetos, que sabiam ler, escrever e fazer contas, sendo precursores de uma nova era que agora tambm incorporava negcios, finanas e habilidades gerenciais. O sculo 20 foi palco de enormes mudanas no gerenciamento de projetos. Frederick Taylor usou o raciocnio de quebrar os elementos de um processo para melhorar a produtividade, criando as tarefas. Henry Gantt, por outro lado, criou a tcnica de traar sequncia e durao das tarefas. O grfico de Gantt utilizado at os dias de hoje. um recurso indispensvel na maioria dos softwares de gerenciamento de projetos. A segunda revoluo industrial introduziu os motores movidos combusto e a eletricidade, que influenciaram as tecnologias de produo em massa. Neste perodo, tambm foram desenvolvidas ou adaptadas tcnicas de coordenao, que deram aos gerentes de projeto mais controle sobre o andamento dos projetos. O Empire State Building uma prova disso. Havia um cronograma bem agressivo, que inclua 60 tipos diferentes de profissionais. Algumas das tarefas foram sobrepostas, de modo a no se perder tempo. Foi o primeiro projeto de construo comercial a utilizar a tcnica de fast-track. Em janeiro de 1930, a escavao do novo edifcio foi iniciada antes da demolio do seu predecessor. Foram construdas quatro lajes e meia por semana, utilizando inovaes que economizaram tempo e recursos. Os nmeros do projeto do Empire State Building so bastante expressivos. Foram demandados trs mil e quinhentos homens e sete milhes de horas. O projeto foi concludo trs meses antes do prazo, com dezoito milhes e trezentos mil dlares abaixo do oramento. A terceira revoluo industrial introduziu computadores, a Internet, e prticas de gesto. FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO
5|
CAPTULO 1
Em 1955, os militares dos EUA inventaram o PERT (Program Evaluation and Review Technique) para determinar o tempo que se levava para completar uma tarefa e identificar o tempo mnimo necessrio para completar um projeto. Em 1957, a DuPont criou o CPM (Critical Path Method) para lidar com vrias tarefas e interaes de um projeto, incorporando algoritmos para definir as atividades do projeto. A Defesa dos EUA tambm introduziu ferramentas de projeto, tais como a estrutura de diviso de trabalho, que organiza o escopo de um projeto agrupando elementos de trabalho do projeto, conhecida como EAP (em ingls, WBS). Na dcada de 70, o Gerenciamento de Projetos tornou-se amplamente utilizado. O PMI (Project Management Institute) foi criado para dar enfoque s tcnicas de projetos. E com isso foram introduzidos os conceitos de Tempo, Custo e Qualidade. Na dcada de 80 houve a incorporao da gesto de riscos para gerenciamento de projetos e na dcada de 90 foram introduzidas certificaes profissionais em gerenciamento de projetos, como o PMP (Project Manager Professional). Em 2013, foi criada a rea de conhecimento que se preocupa exclusivamente com a gesto de Stakeholders, reforando a importncia do bom gerenciamento de todas as partes interessadas no projeto. Segundo o relatrio PMSURVEY.ORG, edio 2012, apenas 8% da alta administrao das organizaes d pouco ou nenhum apoio a iniciativas relacionadas ao gerenciamento de projetos. Com isso, fica claro que o gerenciamento de projetos passou a assumir papel estratgico nas organizaes, e levado muito a srio. Como consequncia natural, a figura do gestor profissional de projetos tambm valorizada. Um dado, do mesmo relatrio, que comprova isso que 27% das organizaes exigem ou pretendem exigir que os profissionais responsveis por projetos sejam certificados PMP. Outros 51% dizem que a certificao vista como um diferencial. Somente 21% das organizaes so indiferentes quanto a ter ou no profissionais certificados. Desde as grandes pirmides at os projetos de alta tecnologia, as prticas de gerenciamento de projetos tm melhorado continuamente. Por este motivo, esta obra pode ser o ponto de partida para o seu aprendizado sobre o tema, mas de forma alguma deve ser o passo final.
Quem o PMI?
O Project Management Institute (PMI) a maior associao sem fins lucrativos do mundo para profissionais de Gerenciamento de Projetos. Seus padres para o gerenciamento de projetos, programas de certificao, programas de pesquisa acadmica e de mercado, captulos e comunidades de prtica so reconhecidos mundialmente e ajudam mais de 700 mil membros, credenciados e voluntrios, em quase todos os pases do mundo a melhorarem suas carreiras e aumentar as chances de sucesso em projetos de todos os tipos e tamanhos, desde a implantao de um servidor de e-mail at a construo de uma hidroeltrica. Dentre as principais linhas de servio do PMI, destacam-se:
Padres Globais (Standard)

Os padres desenvolvidos pelo PMI para o gerenciamento de projetos, programas e portfolio so amplamente reconhecidos - e cada vez mais adotados por empresas e entidades governamentais como modelo. Esses padres so desenvolvidos pelos milhares de voluntrios qualificados e atualizados do PMI, com experincia em todos os tipos de projetos, e estabelecem uma linguagem comum para o gerenciamento de projetos em todo o mundo.
6|
CAPTULO 1
Mas afinal, o que um padro?

Um padro (ou standard) um documento estabelecido em consenso, aprovado por um grupo reconhecido, que prov um guia para uso repetitivo de processos. Em outras palavras, um padro nada mais do que um conjunto de prticas altamente aplicadas, testadas, e atualizadas por profissionais experientes e praticantes da disciplina no dia a dia. Boa prtica significa que na maioria dos casos testados, as chances de sucesso aumentaram com a utilizao destas prticas. Os quatro principais padres mantidos pelo PMI so:
PMBOK
Um das publicaes mais populares do PMI o guia PMBOK (Project Management Body of Knowledge), atualmente na sua 5 edio, com mais de dois milhes de cpias distribudas. O PMBOK considerado a bblia de boas prticas para o gerenciamento de projetos, sendo o seu uso um senso comum para a maior parte da comunidade de profissionais da rea. O PMBOK no uma metodologia, tampouco uma norma da qual voc deve seguir passo a passo para ter xito. Traz recomendaes do que deve ser feito na maioria dos casos para que se tenha sucesso. E como toda boa prtica, suas recomendaes so adaptveis s necessidades de cada organizao. O PMBOK abrange todas as reas de conhecimento em gerenciamento de projetos e apresenta para cada processo as habilidades, ferramentas e tcnicas que aumentam a chance de sucesso de um projeto individual. Isso mesmo, apesar de toda a sua complexidade, o PMBOK focado no gerenciamento de um nico projeto.
OPM3
O OPM3 (Organizational Project Management Maturity Model) o padro do PMI que apresenta as boas prticas para garantir e avaliar o nvel de maturidade das organizaes em gesto de projetos.
Standard for Program Management

o padro do PMI de boas prticas para gerenciamento de programas.
Standard for Portfolio Management

o padro de boas prticas do PMI para gerenciamento de portflio de projetos.
Certificaes
O PMI oferece seis certificaes que atestam conhecimento e competncia, dentre as quais, a de Profissional em Gerenciamento de Projetos (PMP), que conta com mais de 370.000 profissionais certificados em todo mundo. Os salrios e as oportunidades de carreira dos profissionais certificados demonstram que os empregadores reconhecem o valor agregado por aqueles que possuem essas certificaes.
CAPM
A CAPM a certificao de entrada do PMI, equivalente a uma certificao ITIL Foundation, COBIT Foundation ou Cisco CCNA. Isso quer dizer que os requisitos para a certificao CAPM so menores e recomendvel para quem membro de equipes de projeto ou est iniciando na profisso de gerenciamento de projetos. Esta certificao relativamente nova no mercado e ainda no to conhecida como o PMP. Dependendo do seu momento de carreira, pode valer a pena ou no investir em uma certificao CAPM. Se voc est no inicio da carreira em gesto de projetos o PMP no indicado para voc, pois uma certificao para profissionais experientes, que atesta os conhecimentos prticos de gesto de projetos.
7|
CAPTULO 1
O Exame composto por 150 questes de mltipla escolha, sendo 135 delas pontuadas no resultado do seu exame e 15 so questes de teste, no pontuadas no seu resultado. So 3 horas para responder as 150 questes. Abaixo os critrios de Elegibilidade do PMI para esta certificao: 1. Ter no mnimo nvel secundrio; E 2. Ter no mnimo 1500 horas de experincia em projetos; OU 3. Ter no mnimo 23 horas de treinamento formal. Para comprovar estes critrios, voc deve realizar um cadastro no site do PMI e pagar a taxa do exame. O PMI escolhe aleatoriamente candidatos para uma auditoria. Se voc caiu na auditoria, tem 90 dias para enviar a documentao que comprove os critrios acima para o PMI (Comprovante de escolaridade e comprovante das horas de projetos ou certificado do treinamento). Se voc no caiu na auditoria, pode agendar a data do seu exame em at um ano aps o pagamento da taxa. A certificao CAPM vlida por 5 anos e para renovao voc deve, ou refazer o exame, ou certificar-se como PMP. A taxa para o exame em Novembro de 2013 de $225,00 para membros do PMI e $300,00 para no membros. recomendvel que voc afilie-se ao PMI para pagar a taxa com desconto, j que como membro voc tambm tem acesso a uma vasta biblioteca sobre gerenciamento de projetos, alm de baixar gratuitamente uma cpia do guia PMBoK que ser necessrio nos seus estudos. Neste link voc pode baixar um PDF com o guia de bolso do PMI sobre a certificao CAPM (http://goo.gl/vVjL0E). Sempre verifique no site do PMI as informaes atualizadas sobre o exame, quanto a critrios e valores.
PMP
A certificao PMP a mais conhecida de todas e recomendada para gerentes de projeto experientes. Diferente da certificao CAPM, que 100% focada no PMBOK, a prova da certificao PMP composta basicamente por 30% os conhecimentos do PMBOK e os outros 70% so prticas de gesto de projetos e outras habilidades de gesto. So 4 horas para responder 200 perguntas de mltipla escolha, situacionais ou contextualizadas em um caso de negcios. Para renovar a certificao necessrio acumular ao longo de 3 anos 60 PDUs, que so unidades de desenvolvimento profissional. Voc consegue estas PDUs participando de treinamentos, ministrando treinamentos, escrevendo ou lendo artigos, praticando gerenciamento de projetos, etc. O intuito assegurar a atualizao constante do profissional. O Exame composto por 200 questes de mltipla escolha, sendo 175 delas pontuadas no resultado do seu exame e 25 so questes de teste, no pontuadas no seu resultado. Voc ter 4 horas para responder as 200 questes. Abaixo os critrios de Elegibilidade do PMI para esta certificao: Diploma universitrio; Experincia mnima de 3 anos em gerenciamento de projetos e 4.500 horas liderando atividades de projetos 35hrs de treinamento formal OU Diploma de segundo grau Experincia mnima de 5 anos e 6.500 horas liderando atividades de projetos 35hrs de treinamento formal
8|
CAPTULO 1
Para comprovar estes critrios, voc deve realizar um cadastro no site do PMI e pagar a taxa do exame. O PMI escolhe aleatoriamente candidatos para uma auditoria. Se voc caiu na auditoria, tem 90 dias para enviar a documentao que comprove os critrios acima para o PMI (Comprovante de escolaridade, comprovante das horas de projetos e certificado do treinamento). Se voc no caiu na auditoria, pode agendar a data do seu exame em at um ano aps o pagamento da taxa. A taxa para o exame em novembro de 2013 de $405,00 para membros do PMI e $555,00 para no membros. recomendvel que voc afilie-se ao PMI para pagar a taxa com desconto, j que como membro voc tambm tem acesso a uma vasta biblioteca sobre gerenciamento de projetos, alm de baixar gratuitamente uma cpia do PMBoK que ser necessrio nos seus estudos. Neste link voc pode baixar um PDF com o guia de bolso do PMI sobre a certificao PMP (http://goo.gl/5WvXvj ). Sempre verifique no site do PMI as informaes atualizadas sobre o exame, quanto a critrios e valores.
PgMP
A certificao PgMP para gerentes de programas experientes e o ltimo nvel de certificao do PMI. Atualmente, o nmero de profissionais com esta certificao no Brasil de apenas 15. Isso se d pela complexidade e alto custo do processo. Para esta certificao necessrio pagar uma taxa de U$ 1500,00 (sendo membro do PMI), comprovar 6.000 horas de experincia com gerenciamento de projetos e 6.000 horas de experincia como gerente de programas, caso o candidato tenha curso superior. O processo de avaliao consiste em 3 fases. Na primeira fase, o profissional avaliado por um quadro de gerentes de programa quanto a sua experincia profissional. Na segunda fase, o candidato passa por uma prova de mltipla escolha com 170 questes e na terceira fase o candidato passa por uma avaliao 360 graus, onde preenche uma auto avaliao e deve indicar 12 pessoas como referncia para que o avalie. Todas as etapas so desclassificatrias.
Outras certificaes
O PMI tambm lanou trs certificaes especficas. A PMI-ACP certifica profissionais com capacitao em Agile, ou mtodos geis de gesto de projetos. A Certificao PMI-RMP focada em gesto de riscos e a Certificao PMI-SP focada na gesto de cronograma. O profissional com estas certificaes atesta seus conhecimentos especficos nestas disciplinas.
Captulos e Comunidades de Prticas

A maior parte das atividades do PMI ocorre em mais de 265 captulos, bem como nas 39 comunidades de prticas. Estas comunidades, abertas para membros do PMI e lideradas por voluntrios, apoiam o ambiente colaborativo e a disseminao de conhecimento. Os captulos do PMI so escritrios locais responsveis por promover a interao entre profissionais e o incremento da base de conhecimento em boas prticas de gesto de projetos atravs de eventos como treinamentos, workshops, encontros e trabalho voluntrio. As atividades de comunidades de prticas ocorrem online, onde possvel se familiarizar com profissionais de todo o mundo que compartilham o mesmo interesse, seja de um setor da indstria ou mesmo de uma rea de atuao especfica.
9|
CAPTULO 1
Pesquisas
O Programa de Pesquisa do PMI foi criado em 1997 para promover a disciplina e a profisso de gerenciamento de projetos. Desde ento, o PMI investiu mais de 16 milhes de dlares em pesquisa sobre gerenciamento de projetos. Este programa de pesquisa uma parte essencial da misso do PMI de tornar o gerenciamento de projetos algo indispensvel para os resultados dos negcios. O programa cria novos conhecimentos por meio de projetos de pesquisa, trabalhos apresentados em congressos e simpsios, e programas de questionrios de pesquisa. Desta forma, o conhecimento consolidado disseminado atravs de publicaes de pesquisas, jornais acadmicos, conferncias de educao e pesquisa e sesses de trabalho de pesquisa.
10 | CaptuLo 2
Captulo 2 Conceitos Bsicos de Gerenciamento de Projetos

Neste captulo introdutrio, voc ir conhecer os principais conceitos e termos envolvidos no Gerenciamento de Projetos. muito importante que voc os compreenda bem para garantir o melhor aproveitamento do contedo que ser apresentado nos captulos posteriores.
O que um Projeto?
No podemos falar em gerenciamento de projetos sem antes definirmos o conceito de projeto. Em sua opinio, o que um projeto? Uma ideia... Um fluxo... Um cronograma... Uma proposta de governo... A instalao de um sistema operacional? Curiosidade relevante: Do Latim, PROJECTUM, algo lanado frente, que vem de PROJICERE, formado por PRO = frente + JACERE = lanar, atirar. Em outras palavras, projeto algo que voc lana a frente, na linha do tempo. Podemos dizer que projetar nada mais do que estabelecer um alvo a frente ou definir um objetivo. Na prtica, traar uma rota para atingir o alvo (vou acertar uma flecha naquela melancia), elaborar o planejamento (estou mirando na melancia) e executar o planejamento para conseguir o resultado esperado (acertei a flecha na melancia). Segundo o guia PMBoK, Projeto um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo (PMBoK 5ed. pag. 3). Apesar de parecer uma definio simples, no to fcil separar um projeto de uma atividade de rotina. Por isso o enfoque nas palavras temporrio e exclusivo. Um projeto tem inicio, meio e fim bem determinados, e gera um resultado nico. De maneira geral, uma demanda especfica pode ser definida como um projeto a partir das respostas para as seguintes perguntas. Pense em algum caso conhecido ou imagine uma situao em que voc possa aplica-las. Tem incio e fim? Tem escopo limitado? Tem recursos definidos? Gera um resultado nico? Se a sua resposta para todas estas perguntas for positiva, ento voc tem um projeto. Faa um exerccio. Com base nos dois cenrios a seguir, reflita sobre qual deles tem potencial para ser um projeto.
Cenrio um
O funcionrio de uma empresa multinacional precisa que seja instalado em seu computador um software de edio de imagens, j homologado e plenamente suportado pela equipe de TI. Esta solicitao pode ser feita para a central de servios (service desk) em qualquer dia e horrio, inclusive por e-mail ou por meio da intranet. Considere as seguintes caratersticas deste cenrio: Esta instalao j est bem documentada. Outros usurios provavelmente encaminham esta mesma demanda com bastante frequncia. um esforo de baixa complexidade e risco. O computador serve apenas a um usurio. Na pior das hipteses, o usurio ficaria impossibilitado de desempenhar suas atividades por algum tempo, o que no comprometeria a produtividade da empresa de forma significativa.
11 | CaptuLo 2
Cenrio dois
A mesma empresa multinacional decide que o sistema operacional utilizado precisa ser atualizado para todos os usurios nos 10 pases onde tem presena, de forma centralizada, sem interferncia na rotina dos usurios e considerando computadores de mesa e portteis. H uma determinao da alta direo que esta atualizao deve ser concluda, impreterivelmente, nos prximos seis meses. Considere agora as seguintes caratersticas deste cenrio: a primeira vez que este sistema ser distribudo aos usurios da empresa em larga escala. H claramente um prazo para incio e fim da atividade. Este tipo de atualizao no ocorre rotineiramente na empresa (e provavelmente em nenhuma outra empresa). um esforo de alta complexidade e risco. Muitas equipes de TI seriam mobilizadas (incluindo mo de obra temporria terceirizada). Por ter envolvimento de toda a organizao, a probabilidade de algo dar errado maior, bem como as consequncias de alto impacto negativo. Com base nos dois cenrios, qual deles voc consideraria como um projeto? Se a sua resposta foi o cenrio dois, parabns. Voc conseguiu compreender o conceito de projeto!
De onde surgem os projetos?

Projetos podem surgir como resultado de uma das seguintes necessidades ou demandas:
Demanda de mercado
As demandas do mercado podem direcionar a necessidade por um projeto. Por exemplo, uma loja de e-commerce inicia um projeto para oferecer aos clientes a possibilidade de realizar compras atravs de redes sociais, dado a constatao de que a maioria da populao utiliza mais da metade do tempo na Internet usando as redes sociais.
Avano tecnolgico
A tecnologia avana a passos largos. Todo dia h uma nova (e melhorada) verso de algum software, hardware ou eletroeletrnico que voc usa. Com base nos avanos tecnolgicos, as organizaes reformulam seus produtos e servios para obter vantagem competitiva. Por exemplo, uma empresa que adota a tecnologia mobile para disponibilizar acesso dos vendedores ao sistema de vendas atravs de tablets - durante a visita pessoal aos clientes - reduzindo o tempo do processo de vendas em vrias horas.
Solicitao de Cliente
difcil pensar em uma empresa que no tem clientes, sejam eles internos ou externos. A voz do cliente normalmente direciona uma srie de novos projetos. Em uma agncia de publicidade, por exemplo, cada solicitao de um cliente tratada como um projeto.
Requisito Legal
Organizaes do setor privado e governamental geram novos projetos como resultado de novas regulamentaes. Por exemplo, novas regulamentaes de tributao inferem na alterao dos sistemas de vendas. Ou ento novas regras para provedores de telecomunicaes requerem grandes atualizaes na infraestrutura para garantir taxas adequadas de velocidade.
12 | CaptuLo 2
Necessidade Organizacional
Projetos tambm podem surgir a partir de necessidades da prpria organizao. Por exemplo, o projeto de criao de um portal interno (Intranet) surge com a necessidade dos departamentos internos de uma empresa em acessar e compartilhar informaes em um local nico, com o objetivo de melhorar a comunicao e a gesto do conhecimento.
Necessidade Social
Como o prprio nome diz alguns projetos tambm podem surgir a partir de questes de cunho social. Por exemplo, durante um surto de casos confirmados de Dengue, surge a necessidade de mobilizar agentes de sade e voluntrios para um grande projeto com o objetivo de eliminar os potenciais focos da doena.
O que Gerenciamento de Projetos?

O Gerenciamento de Projetos definido como a aplicao de conhecimentos, habilidades e tcnicas para projetar atividades a fim de cumprir com os requerimentos do projeto. Trata-se de uma competncia estratgica para organizaes, permitindo que elas unam os resultados dos projetos com os objetivos do negcio e, assim, possam competir melhor em seus mercados. Existem cinco grupos de processos do gerenciamento de projetos: Incio Planejamento Execuo Monitoramento e Controle Encerramento O conhecimento em gerenciamento de projetos composto por dez reas: Gerenciamento da Integrao Gerenciamento de Escopo Gerenciamento de Custos Gerenciamento de Qualidade Gerenciamento das Aquisies Gerenciamento de Recursos Humanos Gerenciamento das Comunicaes Gerenciamento de Risco Gerenciamento de Tempo Gerenciamento das Partes Interessadas (Stakeholders) Obviamente todos os gerenciamentos dizem respeito a isso. Mas o Gerenciamento de Projetos traz um foco nico delineado pelos objetivos, recursos e a programao de cada projeto.
13 | CaptuLo 2
Na figura acima esto alguns exemplos de conhecimentos, habilidades e tcnicas que podem ser utilizados durante as atividades de um projeto para garantir um resultado bem sucedido. Aplicar conhecimentos, habilidades, ferramentas e tcnicas para a execuo efetiva dos projetos significa utilizar os conhecimentos da rea de atuao em que voc est situado, junto aos conhecimentos de gesto de projetos, com habilidades interpessoais (tambm conhecidas como soft skills), aliado a ferramentas e tcnicas que j esto desenvolvidas e testadas, para garantir que o projeto ser concludo com sucesso.
Gerente de Projetos, o Maestro de um Projeto

No h forma melhor de descrever o papel de um Gerente de Projetos do que o comparando a um maestro. Personagem comum em desenhos animados e filmes humorsticos, o regente - ou maestro, nome italiano pelo qual mais conhecido - um profissional pouco compreendido. Muitos se perguntam qual a razo daquela figura de casaca gesticulando na frente de um grupo de msicos que mal parecem dar-lhe ateno. Fruto desta mesma incompreenso, a dvida mais comum sobre a real necessidade de um condutor, uma vez que os msicos j conhecem a msica e tm a partitura. De fato, a partitura contm todas as indicaes necessrias para se tocar as notas da msica. Entretanto, no devemos confundir a msica com as notas que a compem. Quando comparamos uma mesma msica executada por dois cantores ou instrumentistas diferentes, podemos identificar a interpretao que cada um empresta obra. A interpretao uma espcie de marca pessoal que torna a execuo nica. Nesse caso, seria correto dizer que o maestro toca a orquestra, isto , ele unifica o conjunto dos intrpretes em uma nica expresso, aquela que ele entende como a mais adequada ao contexto. Por definio, o gerente de projetos (o maestro) o principal - e no o nico - responsvel pelo sucesso ou fracasso de um projeto (obra). Esta responsabilidade compartilhada com o time do projeto (a orquestra). O gerente de projetos sempre faz parte de um contexto, no qual esto envolvidos os representantes da prpria organizao e tambm das diferentes organizaes que contribuem para a realizao do projeto (a orquestra) conforme demonstrado na figura seguinte.
Figura O Sistema Total do Projeto Fonte: STUCKENBRUCK, 1978, p.34
14 | CaptuLo 2
O Gerente de Projetos atua como um facilitador e integrador, garantindo que todas as reas envolvidas saibam suas responsabilidades, antecipando problemas que possam ocorrer e realizando um bom planejamento integrado. Alm disso, ele tambm o principal responsvel por equilibrar as restries do projeto, como tempo, custo, escopo, qualidade e recursos humanos. Pode-se afirmar, portanto, que a sua responsabilidade assegurar a realizao do projeto dentro dos padres de desempenho relacionados s metas, prazos e custos, exigindo a integrao de todos os fatores concorrentes, como: administrao da comunicao, recursos humanos, contratos, materiais e riscos.
O efeito HALO
Segundo a Wikipdia o efeito HALO a possibilidade de que a avaliao de um item possa interferir no julgamento sobre outros fatores, contaminando o resultado geral. Este considerado o erro de avaliao mais srio e mais difundido em todo o mundo. No mbito do gerenciamento de projetos esta prtica tambm comum, mesmo que inconsciente. A questo de que o resultado de um projeto pode ser comprometido, quando certos atributos de um gerente de projetos so supervalorizados enquanto outros so subestimados, bastante discutida entre a comunidade de profissionais de gerenciamento de projetos. H razes para acreditarmos, por exemplo, que um profissional com alto nvel de especializao em segurana da informao poderia gerenciar um projeto de certificao digital com certa tranquilidade. Mas se este gerente no tiver certas habilidades bsicas, como liderana e desenvoltura para lidar com conflitos, as chances de o projeto ser bem sucedido sero reduzidas exponencialmente. Ou seja, o gerente de projetos no pode ser o especialista no projeto. Ele deve ser o profissional focado em gerenciamento, para garantir que todos os especialistas envolvidos possam realizar seu trabalho da melhor forma garantindo os resultados. Por outro lado, um profissional da rea de marketing, com habilidades de liderana, gesto de pessoas e comunicao comprovadas, apesar de ter grandes habilidades de gesto, poderia ter dificuldade em gerenciar um projeto de construo civil se no tiver conhecimentos do universo da construo civil. Como visto anteriormente, o gerenciamento de projetos diz respeito aplicao de conhecimentos, habilidades e tcnicas para a execuo de projetos de forma efetiva e eficaz. Via de regra, um gerente de projetos que possua o conhecimento dos cinco grupos de processos, das dez reas do gerenciamento de projetos e as habilidades de gesto necessrias seria capaz de gerenciar projetos de qualquer natureza. Em todo caso o uso do bom senso uma tima opo.
Competncias em Gerenciamento de Projetos

Em linhas gerais, os gerentes de projetos tm a responsabilidade de satisfazer vrias necessidades, seja da equipe, individuais ou de tarefas que precisam ser concludas. Sendo o gerenciamento de projetos uma disciplina estratgica, o gerente de projetos se torna a ponte entre a estratgia e a equipe, e suas competncias afetam diretamente o resultado do projeto. Compreender e aplicar conhecimento, ferramentas e tcnicas que so reconhecidamente boas prticas no suficiente para um gerenciamento de projetos efetivo. Na figura a seguir so demostradas algumas das competncias necessrias para um gerente de projetos utilizando o conceito do CHA (conhecimentos, habilidades e atitudes).
15 | CaptuLo 2
O conhecimento garante que o gerente de projeto tenha segurana sobre o tema e o ambiente em que est situado. Por exemplo, se uma empresa de TI, ele deve ter conhecimento de TI. As habilidades so essenciais para liderar a equipe em busca de resultado bem sucedido, negociar com as partes interessadas e comunicar-se constantemente com a equipe, patrocinador, clientes e todos os demais afetados. Na ultima dimenso, os destaques so para protagonismo, entusiasmo e proatividade. Afinal, um gerente de projetos desmotivado e pessimista no consegue liderar uma equipe para o sucesso. Concorda? O PMBoK 5Ed. cita como habilidades de relacionamento interpessoal essenciais do gerente de projetos: Liderana, Construo do espirito de equipe, Motivao, Comunicao, Influncia, Tomada de deciso, Conscincia poltica e cultural, Negociao, Confiana, Gesto de conflitos, e Coaching
16 | CaptuLo 2
O que um Programa?
Curiosamente, a definio de programa semelhante em todos os inmeros sentidos da palavra: um grupo de elementos que so relacionados e coordenados com o objetivo de gerar um resultado esperado. Nos programas de televiso, a ideia concentrar os inmeros quadros e atraes sob a coordenao de um diretor com o objetivo de entreter as pessoas. No mbito do desenvolvimento de software, os programas consolidam um grupo de instrues que sero executadas por um computador gerando os resultados esperados. o caso de um editor de texto, que traz uma srie de recursos de edio sob uma mesma plataforma com objetivo de permitir que os usurios criem e editem textos de todos os tipos. Para o gerenciamento de projetos, um programa um grupo de projetos relacionados, subprogramas ou atividades do programa, que so gerenciados de modo coordenado para obteno de benefcios e controles que no estariam disponveis se eles fossem gerenciados individualmente. Em um programa de capacitao, por exemplo, podem existir diversos projetos independentes, com gerentes e times de projeto, escopos e prazos diferentes. Embora todos com o objetivo comum de desenvolver os profissionais. Eis alguns exemplos de projetos que poderiam fazer parte deste programa: Projeto de avaliao de competncias - cujo objetivo identificar o perfil, as limitaes de capacitao e as oportunidades de melhoria para cada colaborador. Projeto de capacitao cujo objetivo angariar investimentos para o treinamento dos colaboradores. Projeto de clima organizacional - cujo objetivo identificar e sanar questes relacionadas ao desempenho profissional, como liderana, ambiente de trabalho e outros. Projeto de implementao de plataforma EAD cujo objetivo implementar uma plataforma de treinamentos online que permita a capacitao contnua e flexvel de todo o quadro de colaboradores. Sendo bastante realista, comum ver projetos como estes sendo gerenciados e executados por pessoas e reas distintas, principalmente em grandes organizaes. Isso no necessariamente um problema, mas a probabilidade de ocorrerem trabalhos redundantes ou a m utilizao dos recursos humanos e financeiros enorme. Por este motivo, a coordenao destes projetos por meio de um programa poderia trazer resultados muito melhores.
17 | CaptuLo 2
O que um Portfolio?
O portflio de projetos um conjunto de projetos, programas, subprogramas, subportifolios e operaes gerenciadas em grupo, que tem como principal objetivo atingir os objetivos estratgicos da organizao. Um portflio de projetos no necessariamente tem interdependncia entre seus elementos. Portanto, preciso fazer escolhas certas que agregam valor e que faam jus aos investimentos destinados. Na figura seguinte h uma representao do relacionamento entre projetos, programas e o portflio.
O portflio de projetos pode conter programas, projetos e outras demandas. Um programa certamente contm um grupo de projetos. E um projeto (como j vimos anteriormente) nico e exclusivo. Na prtica, tudo gira em torno do portflio. dele que saem as diretrizes estratgicas que servem como insumo para a priorizao, aprovao, avaliao de impacto, governana, etc. dos programas e projetos. Os programas, por sua vez, fazem o desdobramento destes elementos em nveis mais detalhados e so materializados nos projetos. Por outro lado, o portflio recebe insumos de programas e projetos, como relatrios de desempenho, que permitem confirmar se a estratgia est sendo cumprida, ou mesmo a necessidade de reavali-la.
18 | CaptuLo 2
O que Patrocinador (Sponsor)?

O papel do patrocinador (sponsor), ao contrrio do que naturalmente seria pensado, vai muito alm da viabilizao financeira de um projeto. O patrocinador de um projeto uma das principais partes interessadas de um projeto, e pode ser descrito como um lder visionrio, o elo entre a equipe de gerenciamento de projetos e gesto executiva da organizao. Sua responsabilidade promover o projeto, assim como observar se os benefcios pretendidos esto sendo de fato realizados. Embora normalmente no interfira no dia-a-dia de um projeto, o patrocinador deve facilitar o apoio organizacional necessrio para o sucesso de um projeto. Isso inclui: Auxiliar a manter o projeto alinhado com as metas de negcios e culturais. Comunicar-se em nome do projeto, incluindo seu compromisso pessoal com o sucesso do projeto, e influenciar o amplo comprometimento de outros grupos interessados. Organizar os recursos necessrios para iniciar e sustentar a mudana dentro da organizao, garantindo que os benefcios do projeto sejam plenamente realizados. Facilitar a resoluo de problema, garantindo que as questes do projeto sejam resolvidas de forma eficaz, por toda a extenso organizacional. Isso inclui decises sobre mudanas, riscos, objetivos conflitantes e qualquer outro assunto que esteja fora da alada do gerente de projeto. Fazer o coaching do gerente de projeto quanto aos assuntos operacionais e de negcios. Garantir que as sadas do projeto sejam sustentveis, com processos e pessoas disponveis para mant-los aps a concluso do projeto. Em ltima anlise, a gerncia executiva da organizao responsvel pela formao e nomeao de patrocinadores com estas caractersticas. Caso isso no ocorra, cabe aos gerentes de projeto auxiliar os patrocinadores que estejam dispostos a serem auxiliados e sinalizar um risco ou um problema para aqueles que esto em falta ou no querem apoiar o projeto. H fundamentos para a preocupao em ter um patrocinador efetivo para um projeto. Uma das ltimas pesquisas do PMI Pulse of Professions sinaliza que a existncia de um patrocinador ativo um dos motivos de projetos bem sucedidos. Sendo assim, a ausncia de um patrocnio efetivo aumenta a probabilidade de fracasso do projeto. E como gerente de projeto, voc ser responsabilizado por essa falha. Neste caso, o que o gerente de projetos pode fazer para garantir que o patrocinador tenha uma participao efetiva no projeto? responsabilidade do gerente de projetos identificar e administrar as expectativas das partes interessadas, incluindo o patrocinador, e garantir o engajamento adequado dos mesmos. Por exemplo, o gerente de projetos deve identificar como este patrocinador gostaria de ser abordado, com qual periodicidade, em qual formato, quais so suas expectativas de qualidade, tempo, custo, quais restries so mais importantes para o mesmo, sua sensibilidade com relao a riscos, entre outros.
19 | CaptuLo 2
O que Parte Interessada (Stakeholder)?

Parte interessada (stakeholder) definida como pessoas e organizaes, como clientes, patrocinadores, organizaes executoras e o pblico que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execuo ou trmino do projeto. Elas podem tambm exercer influncia sobre o projeto e suas entregas. Imagine que uma grande obra est prestes a ser realizada pela prefeitura em uma via importante da sua cidade. Algumas partes interessadas mais bvias seriam a prefeitura, os empreiteiros, o engenheiro de obras, os trabalhadores da obra, etc. Contudo, h uma gama de outras partes interessadas, menos bvias, que provavelmente no seriam consideradas. A prpria sociedade seria uma importante parte interessada. Por conta da obra, os moradores prximos regio poderiam ser afetados positivamente, caso a obra trouxesse benefcios com relao ao trfego intenso, ou negativamente, se necessria a desapropriao de algumas residncias. Mesmo em um sentido mais amplo, a sociedade poderia estar interessada no resultado, pois se trata do uso de dinheiro pblico. Notcias veiculadas pela mdia (que tambm uma parte interessada), como superfaturamento, prazo de concluso excedido, falta de organizao, etc. afetariam a reputao do projeto, e consequentemente do gerente do projeto e toda equipe. As partes interessadas esto envolvidas em todo o ciclo de vida de um projeto. Por exemplo, suas necessidades so levadas em conta ao planejar o projeto, e elas tambm podem ajudar a identificar e gerenciar os riscos do projeto. Por conta da influncia que as partes interessadas podem exercer sobre um projeto, fundamental que elas sejam muito bem identificadas e gerenciadas, e suas expectativas claramente compreendidas e priorizadas. Nem sempre ser possvel enderear os interesses e expectativas de todas as partes interessadas. Por este motivo, preciso compreender as necessidades mais importantes de cada parte interessada, e equilibr-las, considerando as restries (ex.: tempo, custo, qualidade...) e priorizando as necessidades que possam trazer benefcios melhores e mais abrangentes. Tomando como exemplo o projeto do Carnaval 2014, a sua maior restrio seria o tempo. O carnaval tradicionalmente, e impreterivelmente, acontece em Fevereiro. J no projeto de construo de um novo Boeing, a maior restrio provavelmente seria a qualidade, por uma questo bvia: a segurana deve estar acima de tudo, mesmo que isso custe mais ou leve mais tempo. Lembre-se: tratar as partes interessadas como membros assistentes da equipe (do projeto) uma atitude bastante saudvel e positiva para o resultado bem sucedido de um projeto. Significa que elas so mantidas informadas e suas opinies e expectativas so levadas em considerao.
Equipe do Projeto X Equipe de Gerenciamento do Projeto

A equipe do projeto, alm do gerente de projetos o grupo que executa o trabalho do projeto (usurios chave, especialistas das reas operacionais e administrativas, representantes do cliente, fornecedores, parceiros de negcios, etc.). O gerente de projetos responsvel pela mobilizao da melhor equipe para o seu projeto e por garantir que saibam suas responsabilidades e assumam o compromisso com as entregas no prazo, custo, escopo e critrios de qualidade esperados. A equipe do projeto pode ser dedicada, onde os membros trabalham 100% focados no projeto, ou compartilhada, onde os membros da equipe trabalham parcialmente alocados no projeto, dividindo seu tempo com outras funes ou outros projetos.
20 | CaptuLo 2
J a Equipe de gerenciamento do projeto, que tambm faz parte do time do projeto, responsvel pelas atividades de gesto do projeto, como: atualizao do cronograma, elaborao de status report, plano de risco, etc. A equipe de gerenciamento do projeto comumente parte do Escritrio de Gerenciamento de Projetos EGP (Project Management Office PMO). Estes profissionais so conhecidos como agentes de PMO.
Escritrio de Gerenciamento de Projetos EGP (Project Management Office PMO)

O PMO definido como uma estrutura de gerenciamento que padroniza os processos de governana relacionados a projetos e facilita o compartilhamento de recursos, metodologias, ferramentas e tcnicas. No uma pessoa, nem um cargo. Os tipos de estruturas de PMOs variam de acordo com o nvel de controle e influncia que eles tenham sobre os projetos da organizao, conforme figura a seguir.
As principais responsabilidades do PMO esto baseadas em trs pilares: Pessoas o PMO pode ser responsvel pela capacitao de pessoal, controle de carga de trabalho e disponibilizao de recursos, como a alocao de gerentes de projetos em projetos especficos. Processos o PMO pode ser responsvel pelo estabelecimento da metodologia para o gerenciamento de projetos, como modelos que devem ser utilizados e politicas que devem ser seguidas. Tecnologia o PMO pode ser responsvel pela implantao e administrao de uma plataforma de gerenciamento de projetos, ex.: Microsoft EPM, Sharepoint. Como voc deve ter percebido, nenhuma responsabilidade do PMO implcita (o PMO pode ser o responsvel por isso ou aquilo). Isso porque o escritrio deve ser moldado de acordo com a necessidade e particularidades de cada organizao. Por uma questo de boa prtica, o PMO deve assumir uma das trs responsabilidades (citadas anteriormente) e limitar-se a ela, sem tentar fazer tudo.
21 | CaptuLo 2
H uma forte tendncia de se criar PMOs, mas as organizaes devem fazer um estudo cauteloso e definir uma estratgia apropriada de implantao, levando em considerao os riscos envolvidos. O desempenho inadequado de um PMO pode criar um cenrio negativo para o gerenciamento profissional de projetos, a ponto de se levar anos para ser revertido.
Tipos de Organizao
Os projetos so influenciados pela cultura, polticas e procedimentos das organizaes das quais fazem parte, ao mesmo tempo tambm inferem nestes itens. Como parte do trabalho do gerente de projetos, necessrio identificar estas influncias e gerenci-las em prol do projeto e da organizao. Uma das principais formas de influncia compreender a estrutura organizacional de uma empresa. Assim ser possvel estabelecer vrios aspectos do gerenciamento de projetos, como por exemplo, a forma como as comunicaes devem ser administradas e os pontos de contato para obter ajuda com alocao de recursos. Dito isso, importante conhecer os tipos mais comuns de estruturas organizacionais, bem como suas vantagens e desvantagens com relao ao nvel de autoridade do gerente de projeto e dos impactos no gerenciamento de projetos nestes ambientes.
Estrutura Funcional
Esta a forma mais comum de organizao. Os membros de equipe esto organizados por especialidade, como engenharia, marketing, operao, contas, TI, etc. Cada funcionrio tem um superior claro. Se o projeto necessitar de informaes ou trabalho de outro departamento, funcionrios transmitem a solicitao ao chefe do departamento, que a comunica ao chefe do outro departamento. Os membros da equipe dividem seu tempo entre o trabalho do projeto e o trabalho normal do departamento.
22 | CaptuLo 2
Estrutura Projetizada
No outro extremo, em uma organizao por projeto, a maior parte da equipe orientada a projetos e o gerente de projetos tem autonomia e autoridade total sobre a equipe. Os membros da equipe trabalham 100% focados no projeto. Ao trmino do trabalho no projeto e/ou quando o projeto termina, os membros da equipe precisam ser designados a outro projeto (na pior das hipteses procurar outro emprego), pois no h um departamento para acomod-los.
Estrutura Matricial
Esta estrutura visa potencializar o que h de melhor em ambas as estruturas, a funcional e a projetizada. Os membros da equipe se reportam a dois chefes: o gerente do projeto e o gerente funcional (por exemplo, gerente de marketing). A comunicao ocorre dos membros da equipe para os dois chefes. Os membros da equipe dividem seu tempo entre o trabalho do projeto e o trabalho normal do departamento. Em uma organizao matricial fraca, o papel do gerente do projeto pode ser semelhante de um facilitador ou coordenador de projetos, cuja atuao principal auxiliar e coordenar as comunicaes, com algum poder para tomar decises, alguma autoridade, e subordinado a um gerente de nvel mais alto. Alm disso, o coordenador de projeto no est 100% alocado no projeto.
23 | CaptuLo 2
Em uma organizao matricial balanceada, aloca-se um Gerente de Projeto que tem maior autoridade no projeto, com 100% de disponibilidade para trabalhar no projeto. O poder compartilhado entre o gerente funcional e o gerente do projeto.
J em uma organizao matricial forte, o poder do gerente do projeto, que tambm trabalha 100% dedicado ao projeto e tem uma equipe especfica de gerenciamento de projetos.
24 | CaptuLo 2
tica e Responsabilidade Profissional

Projetos sempre possuem uma carga considervel de aspectos culturais e polticos, situaes de conflitos de interesse, ou at mesmo o uso de m f. Adicionalmente, o PMI tambm disponibiliza um cdigo de tica e Responsabilidade para profissionais do gerenciamento de projetos, que especifica as obrigaes bsicas com relao a responsabilidade, respeito, honestidade e justia. Este cdigo de tica precisa ser aderido como parte do seu padro de conduta nos projetos do dia a dia e replicado para as equipes de projetos sob a sua gesto.
O Ciclo de Vida
Um ciclo de vida uma progresso por uma srie de estgios de desenvolvimento. O ciclo de vida do projeto descreve o que necessrio fazer para terminar o trabalho, enquanto o processo de gerenciamento de projetos descreve o que preciso fazer para gerenciar o projeto. A seguir vamos detalhar melhor estes dois conceitos.
Ciclo de Vida do Projeto

O ciclo de vida do projeto muitas vezes tambm chamado de metodologia. Em linhas gerais, so as orientaes do que precisa ser feito para produzir as entregas do projeto. Dependendo do setor ou das caractersticas e preferncias da organizao, podem existir tipos diferentes de ciclos de vida de projetos. Tomando como exemplo uma organizao de TI, o ciclo de vida de projetos poderia ser: design, codificao, testes, instalao e entrega para operaes.
Por outro lado, em uma organizao do setor de engenharia civil, o ciclo de vida de projetos poderia ser: viabilidade, planejamento, design, produo e entrega.
25 | CaptuLo 2
Ciclo de Vida do Produto

O ciclo de vida do produto dura da concepo de um novo produto at a sua retirada do mercado. Um produto pode requerer ou abranger muitos projetos durante seu ciclo de vida. Por exemplo, durante a concepo de um produto, pode existir um projeto para determinar os requisitos esperados pelo cliente para aquele produto.
Processo de Gerenciamento de Projetos

Como explicado anteriormente, o ciclo de vida de um projeto ou de um produto pode ser descrito usando muitos termos diferentes, mas h apenas uma forma de descrever o processo de gerenciamento de projetos. O processo de gerenciamento de projetos inclui os grupos de processos de iniciao, planejamento, execuo, monitoramento e controle, e encerramento.
Esses grupos de processos so descritos em mais detalhes no prximo captulo. Neste momento, concentre-se na diferena entre o ciclo de vida de projetos e o processo de gerenciamento de projetos.
26 | CaptuLo 2
O ciclo de vida de um projeto (representado pelas fases do projeto) podem ter diferentes nomes, de acordo com as caractersticas e a filosofia de trabalho de cada organizao. Porm, o mesmo processo de gerenciamento de projetos ser aplicado, universalmente, seja qual for a natureza e o escopo do projeto. Para projetos pequenos, geralmente h um conjunto dos grupos de processos de gerenciamento de projeto para todo o projeto, que podem ser repetidos durante todo o ciclo de vida do projeto. J os grandes projetos precisam ser divididos em fases distintas. No entanto, cada fase do projeto se desenvolve por meio dos grupos de processos de gerenciamento de projetos, conforme figura a seguir.
No incio de um projeto, o gerente do projeto ajuda a criar um termo de abertura para todo o projeto e realiza um planejamento de alto nvel para obter a aprovao do termo de abertura do projeto. No exemplo do grande projeto na figura, o gerente do projeto revisaria o termo de abertura do projeto no incio da fase 1 e confirmaria se a organizao deseja continuar com a fase do ciclo de vida do projeto. Se a organizao optar por continuar, o gerente do projeto faz um planejamento detalhado da fase 2, executa, monitora, controla e encerra a fase 2. Em seguida, o projeto passa para o processo de iniciao da prxima fase, e assim por diante. Lembrando que, no caso de projetos pequenos, esse pode ser exatamente o processo necessrio para gerencia-los. Em grandes projetos, divididos em fases, este mesmo processo o processo pode ser repetido vrias vezes. Por exemplo, em um projeto com uma fase de pesquisa, voc conclui todas as etapas dessa fase, da iniciao at o encerramento, e, em seguida, executa o processo novamente para a fase de design. Embora a impresso passada pelas figuras, o ciclo de vida dos processos de gerenciamento de projetos no linear. Veja a figura a seguir.
27 | CaptuLo 2
Durante a iniciao do projeto, j ocorrem iniciativas de planejamento. Por exemplo, durante a elaborao dos documentos da iniciao do projeto tambm ocorre a mobilizao das equipes, e consequentemente o planejamento de como lidar as pessoas desta equipe. O planejamento do projeto evolui de acordo com a diminuio das incertezas, e muitas vezes isso s acontece conforme algumas entregas so realizadas durante a execuo do projeto. Por razes bvias, devem ser evitadas as alteraes excessivas no plano do projeto, principalmente se no houver justificativas plausveis para tal. Para assegurar que estas alteraes, caso necessrio, sejam controladas e monitoradas de forma estrutura, existem processos de controles de mudanas. Perceba tambm que durante todo o ciclo de vida a evoluo do projeto monitorada e reportada.
28 | CaptuLo 3
Captulo 3 Processos de Gerenciamento de Projetos
Viso Geral
Como visto no captulo anterior, o ciclo de vida do projeto descreve o que necessrio fazer para terminar o trabalho, enquanto o processo de gerenciamento de projetos descreve o que preciso fazer para gerenciar o projeto. O guia PMBOK define processo como um conjunto de aes e atividades inter-relacionadas, que so executadas para alcanar um produto, um conjunto, resultado ou servio pr-definido. Compreender o processo de gerenciamento de um projeto e saber o que deve ser feito e quando a base para se entender todas as entradas, ferramentas, tcnicas e sadas envolvidas no gerenciamento de projetos.
Grupos de Processos
O processo de gerenciamento de projetos inclui cinco grupos de processos:
Iniciao do projeto (Iniciar) - Define e autoriza o projeto ou uma fase do projeto. Planejamento do projeto (Planejar) - Define e refina os objetivos e planeja a ao necessria para alcanar os objetivos e o escopo para os quais o projeto foi realizado. Execuo do projeto (Fazer) - Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto. Monitoramento e controle do projeto (Verificar e agir) - Mede e monitora regularmente o progresso para identificar variaes em relao ao plano de gerenciamento do projeto, de forma que possam ser tomadas aes corretivas quando necessrio para atender aos objetivos do projeto. Encerramento do projeto (Terminar) - Formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.
29 | CaptuLo 3
Entradas, Tcnicas e Ferramentas, e Sadas.

Todo processo, e no somente os Processos de Gerenciamento de Projetos, so compostos por elementos fundamentais: entradas, procedimentos, papis e responsabilidades, indicadores, sadas, etc. Especificamente na disciplina de gerenciamento de projetos, existem trs destes que merecem destaque: as entradas, as tcnicas e ferramentas, e as sadas. As entradas so os gatilhos que disparam o incio de um processo. Alm disso, fornecem embasamento (dados, informaes, conhecimento, sabedoria) para que o processo possa ser realizado. Fazendo uma anlise detalhada de todas as possveis entradas para todos os 47 processos de gerenciamento de projetos descritos pelo guia PMBOK, a lista seria bastante densa. Dentre estas, algumas merecem destaque: Termo de abertura do projeto (Project Charter) Plano de Gerenciamento do Projeto (Project Plan) Fatores ambientais da empresa Ativos de processos organizacionais O fluxo de um processo, e at mesmo o seu resultado, podem ser mais eficientes com o uso de tcnicas e ferramentas. Pense por exemplo nas tcnicas e formas multiplicar ou somar nmeros que nossos professores de matemtica nos ensinavam na poca do ensino fundamental. Sem dvidas estas tcnicas permitiram que no somente os resultados das operaes com nmeros fossem assertivos, mas tambm que fossem realizados em menos tempo. Para o gerenciamento de projetos tambm funciona assim. Existem inmeras tcnicas e ferramentas que podem ser usadas nos diversos processos, algumas especificamente para determinados processo, e outras mais genricas que podem ser usadas na maioria deles. Dentre estas, podemos destacar: Julgamento de especialistas Reunies Tcnicas de facilitao Por fim, todo processo gera um resultado, ou uma sada. Apenas para ttulo de curiosidade, se considerando todos os principais documentos resultantes dos processos de gerenciamento de projetos preconizados pelo guia PMBOK, chegamos a mais de 60 possveis sadas/resultados. Alguns destes documentos so bastante especficos, outros serviro de base para o planejamento do projeto. o caso do termo de abertura do projeto, principal resultado/sada dos processos de iniciao, que tambm serve como principal entrada para os processos de planejamento. Voc ir conhecer o termo de abertura do projeto e outras sadas importantes de processos de gerenciamento de projetos ao longo dos prximos captulos.
30 | CaptuLo 3
reas de Conhecimento
Uma rea de conhecimento representa um conjunto completo de conceitos, termos e atividades que integram um campo de atuao profissional, um campo do gerenciamento de projetos ou uma rea de especializao. Em termos prticos, as reas de conhecimento agrupam processos que possuem assuntos em comum. Por exemplo, o Gerenciamento de Partes Interessadas do Projeto uma rea de conhecimento que envolve todos os processos de identificao, gerenciamento, engajamento e controle das partes interessadas, mesmo estes processos sendo parte de diferentes grupos de Processos de Gerenciamento de Projetos (iniciao, planejamento, execuo, e monitorao e controle). As reas de conhecimento so usadas na maioria dos projetos, na maior parte do tempo. Em linhas gerais, a maioria dos projetos ter envolvimento com todas as reas de conhecimento, porm, voc pode ter algum projeto onde no haja nenhuma aquisio, por exemplo. As equipes de projetos podem utilizar as dez reas de conhecimento descritas, alm de outras reas de conhecimento, se apropriado.
reas de Conhecimento
Distribuio dos Processos nos Grupos
31 | CaptuLo 3
Os 47 processos identificados no guia PMBOK so agrupados em 10 reas de conhecimento, que voc conhecer com mais detalhes a seguir.
Gerenciamento da Integrao do Projeto

O Gerenciamento de Integrao do Projeto est comprometido com cinco processos: Desenvolver o Termo de Abertura do Projeto, Desenvolver o Plano de Gerenciamento do Projeto, Orientar e Gerenciar o Trabalho do Projeto, Monitorar e Controlar o Trabalho do Projeto, Realizar o Controle Integrado de Mudanas e Encerrar o Projeto ou Fase. Esta rea de conhecimento se refere identificao, definio, combinao, unificao e coordenao de todos os aspectos do projeto e altamente interativo. Esta natureza interativa de projetos d-se pelo nvel de incerteza que vai diminuindo conforme o projeto avana e diversos acontecimentos que, muitas vezes so imprevisveis no incio do projeto, vo gerando a necessidade de atualizar o planejamento, aprimorar a execuo ou o controle do trabalho, controlar de forma ordenada estas mudanas e garantir um encerramento adequado. Por exemplo, o grupo de processos de planejamento gera um plano do projeto que utilizado no incio da execuo das atividades do projeto e atualizado conforme a execuo avana.
Gerenciamento do Escopo do Projeto

Esta rea de conhecimento engloba seis processos: Planejar o Gerenciamento do Escopo, Coletar Requisitos, Definir Escopo, Criar EAP, Verificar o Escopo e Controlar o Escopo. Basicamente, esta rea de conhecimento se preocupa com o trabalho que necessrio para completar o projeto e em garantir que ser feito apenas o necessrio. Os processos desta rea envolvem o detalhamento dos requisitos do produto do projeto, com a delimitao do que ser entregue durante o projeto e em como estas entregas sero verificadas para garantir que tudo que foi solicitado, foi concludo, nada mais e nada menos.
Gerenciamento do Tempo do Projeto

Esta rea de conhecimento engloba sete processos: Planejar o Gerenciamento do Cronograma, Definir as Atividades, Sequenciar as Atividades, Estimar os Recursos das Atividades, Desenvolver o Cronograma e Controlar o Cronograma. O Gerenciamento do Tempo do Projeto se preocupa em garantir o trmino pontual do projeto e para isso, garante a estimativa adequada de durao das atividades do projeto para criao e controle do cronograma do projeto.
Gerenciamento dos Custos do Projeto

Como o prprio nome j diz, o Gerenciamento dos Custos do Projeto gira em torno de custos e oramento, englobando quatro processos: Planejar o Gerenciamento dos Custos, Estimar os Custos, Determinar o Oramento e Controlar os Custos. As atividades desta rea de conhecimento estabelecem estimativas e controle dos custos e do oramento do projeto e mantm a vigilncia sobre os custos para assegurar que o projeto permanece dentro do oramento aprovado. Dependendo da complexidade do projeto, estes processos podem precisar do envolvimento de mais de uma pessoa.
32 | CaptuLo 3
Gerenciamento da Qualidade do Projeto

Esta rea de conhecimento composta por trs processos: Planejar a Qualidade, Realizar a Garantia da Qualidade e Controlar a Qualidade. O Gerenciamento da Qualidade do Projeto assegura que o projeto cumpra com os requisitos que se prope a produzir, tanto do projeto, quanto do produto do projeto. Seus processos medem o desempenho geral do projeto e do produto do projeto, monitoram os resultados e os compara aos padres de qualidade definidos no processo de planejamento do projeto, para assegurar que o cliente ir receber o resultado (produto, servio, etc.) que ele comprou.
Gerenciamento dos Recursos Humanos do Projeto

Esta rea de conhecimento composta por quatro processos: Desenvolver o Plano de Recursos Humanos, Mobilizar a Equipe do Projeto, Desenvolver a Equipe do Projeto e Gerenciar a Equipe do Projeto. O Gerenciamento dos Recursos Humanos do Projeto envolve todos os aspectos da gesto de pessoas e interao pessoal, incluindo liderana, coaching, lidar com conflitos, etc. Em outras palavras, estes processos visam garantir que a equipe adequada estar preparada e motivada para realizar o trabalho do projeto. Estas habilidades, ou parte delas, sero necessrias no somente ao Gerente de Projetos, mas tambm para as diversas partes interessadas no projeto, como membros da equipe e clientes.
Gerenciamento da Comunicao do Projeto

Esta rea de conhecimento composta por trs processos: Planejar as Comunicaes, Gerenciar as Comunicaes e Controlar as Comunicaes. O Gerenciamento da Comunicao do Projeto busca assegurar que toda a informao do projeto, incluindo planos de projeto, avalies de risco, anotaes, etc. sejam coletadas e documentadas. Este processo tambm assegura que a informao seja distribuda e compartilhada com as partes interessadas apropriadas. Garante tambm que a informao de um projeto encerrado seja arquivada e usada como uma referncia para futuros projetos, na forma de informao histrica.
Gerenciamento dos Riscos do Projeto

Esta rea de conhecimento composta por seis processos: Planejar o Gerenciamento dos Riscos, Identificar os Riscos, Realizar a Anlise Qualitativa dos Riscos, Realizar a Anlise Quantitativa dos Riscos, Planejar Resposta aos Riscos, e Controlar os Riscos. O Gerenciamento de Riscos do Projeto se preocupa em identificar os riscos e planejar (no sentido de se preparar) para os riscos potenciais que possam causar algum impacto no projeto. Normalmente as organizaes combinam vrios destes processos em apenas um passo. O mais importante que todos os riscos sejam identificados, e para aqueles que possam causar grandes consequncias (negativas) aos objetivos do projeto, sempre exista uma ao de resposta apropriada que reduza ou elimine o impacto do risco. caso ele ocorra ou possa ocorrer. Tambm devemos nos preocupar aqui em aumentar o impacto ou probabilidade de um risco positivo e da mesma forma, ter uma ao de resposta.
33 | CaptuLo 3
Gerenciamento das Aquisies do Projeto

Esta rea de conhecimento composta por quatro processos: Planejar as Aquisies, Conduzir as Aquisies, Administrar as Aquisies, e Encerrar as Aquisies. O Gerenciamento de Aquisies do Projeto est relacionado s aquisies de produtos ou servios de fornecedores externos, sempre sob a perspectiva do comprador e visa garantir o planejamento e a conduo apropriada das aquisies necessrias para realizar o trabalho do projeto.
Gerenciamento das Partes Interessadas do Projeto

Recm-includa na 5 edio do guia PMBOK, o que refora a importncia das partes interessadas nos projetos, esta rea de conhecimento engloba quatro processos: Identificar as Partes Interessadas, Planejar o Gerenciamento das Partes Interessadas, Gerenciar o Engajamento das Partes Interessadas e Controlar o Engajamento das Partes Interessadas. O Gerenciamento das Partes Interessadas do Projeto se refere identificao de pessoas, grupos ou organizaes que podem impactar ou serem impactadas pelo projeto. Tambm tem enfoque na comunicao continua com as partes interessadas, para compreender suas necessidades e expectativas, enderear questes no momento em que acontecem, gerenciar conflitos de interesse e fomentar o engajamento apropriado das partes interessadas nas decises e atividades do projeto.
34 | CaptuLo 4
Captulo 4 Aplicando as Boas Prticas de Gerenciamento de Projetos

A partir deste captulo voc vai conhecer a aplicao prtica de cada um dos 47 processos das 10 reas de conhecimento em uma sequencia lgica para gerenciar um projeto (Iniciao, Planejamento, Execuo, Monitorao e Controle, e Encerramento). Para facilitar a conceituao prtica e aprimorar o seu aprendizado, ser utilizado um estudo de caso fictcio da SOCIALLY, uma empresa de Tecnologia da Informao, dona de uma das redes sociais mais promissoras da Internet e que est buscando expanso no mercado. Por conta disso, a SOCIALLY tomou a deciso de construir um datacenter prprio. Este projeto de construo do novo Data Center ser a nossa referncia e objeto de estudo para os prximos captulos. Embora o estudo de caso tenha sido baseado em informaes obtidas a partir de projetos reais da mesma natureza, a inteno no descrever com exatido toda a complexidade da construo de um Data Center. O estudo de caso nada mais do que um arcabouo para a apresentao dos conceitos envolvidos em cada um dos processos de gerenciamento de projetos de forma mais ldica, facilitando o seu entendimento.
Estudo de Caso: a Empresa SOCIALLY

Como j foi dito, conhecer a rea de atuao da qual o seu projeto est inserido essencial para o gerenciamento efetivo do projeto. Para isso, vamos apresentar a empresa SOCIALLY. A SOCIALLY uma empresa global de Tecnologia da Informao que est em rpida ascenso. A empresa dona de uma rede social que vem conquistando novos adeptos e desbancando as redes sociais dominantes. O conselho da administrao, pensando na estabilidade da empresa, considera que um bom momento para investir em outros segmentos de atuao, visto que o nicho de redes sociais bastante instvel. A SOCIALLY tambm est bastante preocupada com a segurana dos dados pessoais de seus clientes/usurios e com o custo operacional de hospedagem da sua plataforma, que tem aumentado exponencialmente com a popularidade de sua rede social. Dado este cenrio, algumas diretrizes estratgicas foram definidas, e dentro do portflio de projetos definido surge a iniciativa batizada de projeto Data Waterfall, cujo objetivo construir um Data Center prprio. Nas prximas sees, voc ser conduzido a um passeio por todo o ciclo de vida do projeto Data Waterfall utilizando todas as boas prticas de gerenciamento de projetos preconizadas pelo PMI.
Iniciando o Projeto
Por se tratar do marco zero do projeto, precisamos garantir que est claro o que esperado do projeto em alto nvel, ou seja, ainda sem detalhamentos complementares, alocar um gerente de projetos e iniciar formalmente o projeto. Alm de alinhar as expectativas das partes interessadas com o propsito do projeto, dando a eles visibilidade sobre o escopo macro e objetivos do projeto, mostrando como a participao deles ir permitir que as expectativas sejam alcanadas. Este grupo de processos extremamente importante, pois aqui sero estabelecidas as bases para o planejamento do projeto.
35 | CaptuLo 4
Desenvolvendo o Termo de Abertura do Projeto (Project Charter)

O termo de abertura do projeto uma forma de oficializar a existncia de um projeto, dando ao gerente de projetos carta branca para usar recursos organizacionais em atividades do projeto. Alm disso, o termo de abertura do projeto enderea as perguntas fundamentais: 1. Por que o projeto foi concebido? 2. Quais resultados esperamos conseguir com a concluso do mesmo? 3. O que dever ser feito para entregar os resultados esperados? 4. Quem dever trabalhar no projeto? 5. Quando se espera que o projeto termine? 6. Quanto se espera gastar com o projeto? Para desenvolver um termo de abertura do projeto adequado, as seguintes entradas devem ser consideradas: 1. A especificao de trabalho do projeto (Project Statement of Work SOW), com uma descrio dos produtos, servios ou resultados a serem entregues por um projeto. Neste documento, geralmente temos os seguintes itens: - As necessidades do negcio. Se as mesmas esto baseadas em demandas de mercado, avanos tecnolgicos, regulamentaes, etc. - Quais so as caractersticas do produto, servio ou resultado que o projeto se prope a criar. - Quais metas e objetivos do plano estratgico da empresa esto sendo endereados. - Como o projeto ir contribuir com este plano estratgico. A especificao do trabalho do projeto justifica a sua existncia, o motivo da sua criao e quais resultados se espera alcanar com o mesmo. O Gerente de Projetos da SOCIALLY recebeu o plano estratgico da diretoria onde constam as informaes de resultados financeiros esperados pelo projeto, alm dos benefcios com relao a imagem da companhia. 2. O Caso de Negcio (Business Case), que contm a informao necessria sob a perspectiva do negcio para justificar o investimento em um projeto. No caso da SOCIALLY, o departamento de Marketing elaborou um Caso de Negcios que contem a expectativa financeira em cinco anos em relao construo do novo Data Center, a demanda de mercado e uma anlise da concorrncia. O gerente de projetos utiliza estas informaes em conjunto com outros especialistas para garantir que a realizao do projeto atenda os objetivos de negcio. 3. Os acordos que podem definir as intenes iniciais de um projeto e influenciar o seu planejamento, como custo, prazo e qualidade. Pode ser necessrio um acordo caso: - O projeto esteja atendendo alguma demanda de um cliente e esta demanda possua os requisitos acordados. - J exista a determinao de algum fornecedor externo que ir participar de alguma entrega deste projeto e h um contrato estabelecendo as regras do jogo. No caso da SOCIALLY no existe nenhum contrato de cliente relacionado a construo do Data Center. 4. Fatores ambientais da empresa, como regulamentaes ou padres da indstria, estrutura e cultura organizacional, e condies do mercado. A SOCIALLY, por ser uma empresa de TI, tem uma srie de boas prticas e padres que podem ser adotados para garantir a qualidade do projeto, como certificaes ISO 27000, certificao TIER 3, etc.
36 | CaptuLo 4
5. Ativos de processos organizacionais. So processos que a empresa j tenha estabelecido que devem ser seguidos para a conduo adequada do projeto. Geralmente o Escritrio de Projetos consultado nesta fase do projeto para verificar informaes histricas de projetos anteriores, templates e fluxos de trabalho que devem ser adotados, polticas e procedimentos a serem seguidos. O Gerente de Projetos da SOCIALLY foi informado, nesta etapa, pelo EGP da organizao que existe um sistema de gerenciamento de projetos integrado que deve ser utilizado como repositrio de documentos e comunicao com as partes interessadas. Tambm que neste repositrio, o mesmo poder encontrar informaes de outros projetos de infraestrutura da empresa que podem ser utilizados como benchmark para o novo projeto. Vamos ver agora qual a necessidade da SOCIALLY que endereou a criao do projeto: Devido ao alto custo do contrato de hospedagem e a recente exposio de dados da base de usurios da plataforma de rede social, e decidida a ampliar o seu leque de ofertas no mercado de Tecnologia da Informao, a SOCIALLY reconhece a necessidade de construir um Data Center prprio na regio de Londrina/PR (Este ser o produto do projeto), certificado nos principais padres e principais normas internacionais de qualidade, segurana e sustentabilidade (Estes so requisitos do seu produto do projeto). Alm de acelerar a economia local da regio de Londrina, a SOCIALLY espera melhorar a sua credibilidade e potencializar a sua penetrao e posicionamento no mercado, atravs de servios de hosting (Estes so benefcios do projeto). Como objetivo estratgico, prope-se a reduo de 30% do custo operacional e 100% os servios migrados do atual provedor de hosting para o Data Center prprio, com capacidade para receber at 10 mil servidores (Estes so objetivos mensurveis do seu projeto). O investimento previsto 70 milhes de reais (Este o oramento de alto nvel), onde foram includos o contrato com a construtora responsvel pela obra de construo do prdio e instalaes do Data Center, o contrato para apoio consultivo da consultoria externa na adequao de processos e preparao para as auditorias de certificao e o contrato com o fornecedor de hardware para a disponibilizao de servidores com baixo consumo de energia (estes fazem parte da equipe do projeto). O termo de abertura do projeto contm uma grande variedade de informaes. Por mais que estas informaes ainda estejam em alto nvel, no seria vivel que fossem obtidas somente atravs do conhecimento e opinio do gerente de projetos. Por isso, convm obter uma opinio especializada. A opinio especializada aplicada a todos os detalhes tcnicos e de gerenciamento do projeto e fornecida por qualquer grupo ou pessoa com conhecimento ou treinamento especializado, como: Unidades funcionais internas da organizao Consultores Partes interessadas (todas elas) Associaes profissionais e tcnicas Setores econmicos Especialistas no assunto PMO
37 | CaptuLo 4
No projeto Data Waterfall, foram chamados os seguintes especialistas para a construo do termo de abertura: O engenheiro responsvel pela construtora contratada para realizar a obra de construo do novo Data Center; O consultor externo contratado para apoiar a adequao do sistema de gesto integrada e preparao para as auditorias de certificao das normas ISO20000, ISO27000 e a certificao TIER III; O responsvel pela infraestrutura predial; Profissionais das diversas reas internas de TI, como infraestrutura, sistemas, telecomunicaes e segurana da informao. (Este pessoal tambm faz parte da equipe do seu projeto)
Imagine agora de que forma as informaes necessrias para o desenvolvimento do termo de abertura do projeto poderiam ser extradas de uma equipe multidisciplinar, com diferentes linhas de raciocnio, especializaes, expectativas e personalidades. Neste momento as tcnicas de facilitao, como brainstorming, resoluo de conflitos e soluo de problemas podem ajudar as equipes e pessoas a realizarem tanto estas quanto outras atividades do projeto. O resultado deste processo o prprio termo de abertura do projeto, que, como j falamos, autoriza formalmente a existncia de um projeto, d a direo e concede ao gerente do projeto a autoridade para aplicar os recursos organizacionais nas atividades do projeto. O termo de abertura do projeto contm: Propsito do projeto Objetivos e critrios de sucesso mensurveis Requerimentos de alto nvel Premissas e restries do projeto Descrio do projeto de alto nvel Descrio dos primeiros riscos mapeados Macro-cronograma de entregas, ou resumo do cronograma de marcos Oramento liberado Gerente de Projetos alocado, responsabilidade e nvel de autoridade Lista inicial das Partes Interessadas Formalizao de Lder e Patrocinador do Projeto
Identificando as Partes Interessadas

Um projeto bem sucedido depende da identificao adequada das partes interessadas, desde o incio do projeto ou fase do projeto. Entende-se como identificao adequada das partes interessadas a anlise do seu nvel de interesse, expectativas individuais, sua importncia e influncia. Convm que as partes interessadas sejam classificadas de acordo com o seu interesse, influncia e engajamento no projeto. Com isso, o gerente de projetos pode se concentrar nos relacionamentos necessrios para garantir o sucesso do projeto.
38 | CaptuLo 4
Como entradas para a identificao das partes interessadas, destacam-se: O termo de abertura do projeto, que pode fornecer informaes sobre as partes internas e externas relacionadas e afetadas pelo resultado ou pela execuo do projeto. Os documentos de aquisio, quando o projeto for resultado de uma atividade de aquisio ou estiver baseado em um contrato estabelecido. Neste caso, fornecedores e outras partes envolvidas em um contrato tambm devem ser considerados como partes interessadas do projeto. Os fatores ambientais da empresa e os ativos de processos organizacionaistambm podem influenciar a identificao das partes interessadas. Ex.: a organizao j possui modelos para registro de partes interessadas ou considera que por se tratar de uma empresa do governo, a populao em geral deve ser uma parte interessada no projeto. Como utilizaremos as entradas do Projeto Data Waterfall para identificar as partes interessadas: O Termo de Abertura do Projeto j apresenta uma descrio inicial e de alto nvel das partes interessadas. Pode ser utilizado como um bom ponto de partida, otimizando o tempo dispensado nesta atividade. O projeto envolve a contratao de pelo menos trs fornecedores de servios: a construtora que ir realizar a obra da construo do Data Center, a consultoria em gesto que ir apoiar a preparao para as certificaes do Data Center e do servio de hosting e o fornecedor de hardware que ir disponibilizar arquiteturas de baixo consumo de energia. Estes fornecedores devem ser identificados como importantes partes interessadas no projeto. Conhecer os fatores ambientais da empresa ajuda a classificar melhor as partes interessadas e a compreender as melhores formas de relacionamento. Por ser uma empresa brasileira, a SOCIALLY tem funcionrios com um perfil mais amistoso (tpico de povos latinos). Por outro lado, fatores como qualidade e pontualidade poderiam ser interpretados de forma mais rigorosa nos escritrios do Japo e Alemanha, por exemplo. Os ativos de processos organizacionais disponibilizados pelo EGP da SOCIALLY, como modelos de registros das partes interessadas e lies aprendidas em projetos anteriores facilitam o registro das partes interessadas do projeto Data Waterfall. A opinio especializada uma forma de garantir a ampla identificao e listagem das partes interessadas. Reunies de anlise de perfis tambm podem ser concebidas para desenvolver o entendimento das principais partes interessadas do projeto. Os interesses, as expectativas e a influncia das partes interessadas que devem ser considerados durante todo o projeto, podem ser obtidos atravs da coleta e anlise sistemtica de informaes quantitativas e qualitativas, definida no guia PMBOK como Anlise de Partes Interessadas. Geralmente, a anlise de partes interessadas segue as seguintes etapas: 1. Identificar todas as potenciais partes interessadas do projeto e as informaes relevantes (papis, departamentos, interesses, nvel de influncia, etc.). 2. I dentificar impacto ou apoio potencial que cada parte interessada poderia gerar e classifica-los a fim de definir uma estratgia de abordagem. 3. Avaliar como as principais partes provavelmente reagiro ou respondero em vrias situaes, a fim de planejar como influenci-las para aumentar o seu engajamento e mitigar potenciais impactos negativos. Existem vrios modelos de classificao que podem ser usados na anlise de partes interessadas, como grau de poder/interesse, grau de poder/influncia grau de influncia/impacto e modelo de relevncia.
39 | CaptuLo 4
Pergunta: Qual seria uma abordagem interessante para a anlise das partes interessadas do projeto Data Waterfall? Provvel resposta: A figura a seguir apresenta um modelo de classificao de grau de poder/interesse aplicado ao projeto Data Waterfall, onde identificamos: A. Acionistas B. Prefeitura de Londrina C. Usurios (plataforma de rede social) D. Novos Fornecedores E. reas de infraestrutura de TI F. reas de desenvolvimento de sistemas G. Fornecedor atual (hosting)
A partir deste primeiro modelo de classificao, podemos ir um pouco alm, mapeando a provvel reao esperada para cada parte interessada e aes a serem tomadas, para potencializar as influncias positivas e/ou minimizar as negativas, conforme figura a seguir.
40 | CaptuLo 4
Como vimos no modelo de classificao, os acionistas tm alto poder de influncia e alto interesse no projeto, portanto devem ser mantidos prximo, bem informados, e suas expectativas quanto aos resultados do projeto devem ser garantidas. Se possvel, seria conveniente que participassem do projeto como responsveis por alguma entrega, mesmo que seja uma entrega simples, relacionada s comunicaes para sensibilizar a organizao. a parte interessada que nos exige maior ateno. A migrao para um Data Center prprio transparente para os usurios da rede social, que por isso uma parte interessada com pouco ou nenhum interesse. Por outro lado, possuem um alto poder de influenciar negativamente o projeto, por exemplo, se houver algum tipo de indisponibilidade durante a migrao dos servios, causando reclamaes, insatisfao e ferindo a credibilidade da SOCIALLY. Tanto a prefeitura quanto os novos fornecedores podem ser influenciados pelo projeto. O novo Datacenter ir gerar novos empregos na regio e maior arrecadao tributria para a prefeitura. Tambm ir gerar uma boa receita para os fornecedores contratados para construo do prdio, preparao para as certificaes e para fornecimento de novas tecnologias de hardware. Neste caso, a preocupao deve ser em mant-los informados sobre o andamento e os impactos do projeto. O caso do fornecedor atual de hospedagem mais preocupante, pois j sabido que o contrato atual no deve ser renovado, uma vez que a organizao pretende hospedar os servios em um Data Center prprio. Devido reao j esperada de oposio, a comunicao com esta parte interessada deve ser mais prxima, com o objetivo de reduzir a influncia negativa. Por exemplo, poderia ser discutido arranjo recproco entre as duas empresas, onde uma emprestar sua infraestrutura para a outra caso seja necessrio, ou ento que as duas empresas mantenham uma rea externa independente para uso em caso de desastres. Finalmente, no caso da parte interessada que tem pouca influncia e pouco interesse, como o caso da rea de desenvolvimento de software, convm monitorar se alguns destes fatores no sero alterados ao longo do projeto. Com isso gera-se o principal resultado do processo de identificao das partes interessadas: o registro das partes interessadas. Este registro inclui todos os detalhes relativos s partes identificadas, incluindo: Informaes de identificao Informaes de avaliao Classificao das partes interessadas Vale lembrar que o registro das partes interessadas um documento dinmico que no s pode como deve ser consultado e atualizado regularmente, pois partes interessadas podem ser alteradas ou adicionadas durante o ciclo de vida do projeto.
Planejando o Projeto
Este o estgio mais intenso de um projeto, envolvendo processos de todas as reas de conhecimento. Gerenciar bem um projeto requer planejamento cuidadoso, inteligente e profissional. Em linhas gerais, o planejamento: Garante a compreenso clara de quais so as entregas do projeto, e das expectativas com relao a tempo, custo e qualidade destas entregas. D condies de reao ao gerente de projetos quando algo inesperado afetar alguma dimenso do projeto. Prov embasamento para alocao e motivao dos melhores recursos disponveis para cumprir com os requisitos que geraram a demanda.
41 | CaptuLo 4
O planejamento adequado de um projeto permite prever questes que s poderiam ser identificadas se a atividade fosse executada duas ou trs vezes, e aumenta exponencialmente a eficincia das entregas de um projeto. Como gerente de projetos, sua misso garantir o sucesso de um projeto. Isso significa entregar o que esperado, no prazo certo, a um custo justificado, com a qualidade apropriada. Em sua opinio, seria possvel fazer isso sem um bom planejamento?
Planejando o Gerenciamento do Projeto

Antes mesmo de planejar o projeto, voc precisa planejar como ir lidar com o gerenciamento do projeto e suas questes importantes, como escopo, tempo, custo, qualidade, comunicao, recursos humanos, aquisies, partes interessadas e riscos. Por exemplo, no seria apropriado desenvolver um plano de resposta aos riscos do projeto, sem antes saber quais so as regras de identificao de um risco (o que preciso considerar como gatilho de um risco?), a priorizao de um risco (a priorizao baseada em impacto x probabilidade? As categorias so baixa, mdia e alta?) e quais as medidas que devem ser tomadas para cada tipo de risco (quando aceitar o risco, transferir o risco ou mitigar o risco?). O guia PMBOK apresenta 10 processos de Planejar o Gerenciamento que, no por coincidncia, remete as reas de conhecimento. Como um dos resultados/sadas destes processos geram-se os Planos de Gerenciamento. Estes planos documentam a estratgia para lidar com o gerenciamento do projeto e todos os seus aspectos (as reas de conhecimento). Os planos serviro com base tanto para o estgio de execuo quanto para o prprio estgio de planejamento do projeto. Por exemplo, o Plano de Gerenciamento do Cronograma uma entrada para a definio do prprio cronograma do projeto, que tambm um processo de planejamento. Outro exemplo seria o Plano de Gerenciamento das Partes Interessadas, que uma entrada para o processo de Gerenciar o Engajamento das Partes Interesses (este um processo de execuo). A seguir os planos de gerenciamento sero descritos com mais detalhes.
Plano de Gerenciamento do Projeto

O Plano de Gerenciamento do Projeto uma sada do processo Planejar o gerenciamento do Projeto e serve como um documento central, definindo a base de todo trabalho do projeto, como ele ser executado, monitorado e controlado, e encerrado. O plano de gerenciamento do projeto ultrapassa os limites do estgio de planejamento. O seu contedo desenvolvido e atualizado progressivamente por meio de uma srie de processos integrados at o encerramento do projeto. Ele integra e consolida todos os planos de gerenciamento auxiliares e linhas de base dos processos de planejamento. Uma vez estabelecido, o plano de gerenciamento do projeto s pode ser modificado por meio de uma mudana, que deve ser gerada e aprovada atravs do processo de realizao e controle integrado de mudanas. Como ponto de partida para o desenvolvimento deste plano, considera-se as informaes de alto nvel do termo de abertura do projeto e as sadas de outros processos, que so integradas para criar o plano de gerenciamento do projeto. Quaisquer linhas de base e planos auxiliares de gerenciamento que sejam sadas de outros processos de planejamento podem ser entradas para este plano. Alm disso, as mudanas nesses documentos podem requerer atualizaes no plano de gerenciamento do projeto.
Plano de Gerenciamento do Escopo

O Plano de Gerenciamento do Escopo uma sada do processo Planejar o Gerenciamento do Escopo e descreve como o escopo ser definido, desenvolvido, monitorado, controlado, e verificado. Seus componentes incluem: Os planos auxiliares aprovados do plano de gerenciamento do projeto que so usados para criar o plano de gerenciamento do escopo e influenciar a abordagem adotada no planejamento do escopo e no gerenciamento do escopo do projeto. O termo de abertura do projeto que fornece o contexto de projeto necessrio para planejar os processos de gerenciamento do escopo, como a descrio em alto nvel do projeto e das caractersticas do produto resultante da especificao do trabalho do projeto.
42 | CaptuLo 4
Plano de Gerenciamento dos Requisitos

O Plano de Gerenciamento dos Requisitos tambm uma sada do processo Planejar o Gerenciamento do Escopo e descreve como os requisitos sero analisados, documentados e gerenciados.
Plano de Gerenciamento do Cronograma

O Plano de Gerenciamento do Cronograma uma sada do processo Planejar o Gerenciamento do Cronograma e estabelece os critrios e as atividades para o desenvolvimento, monitoramento e controle do cronograma. O desenvolvimento deste plano embasado principalmente pelo plano de gerenciamento do projeto, que fornece informaes importantes como a Linha de base do escopo (especificao do escopo do projeto e os detalhes da estrutura analtica do projeto, ou EAP, usados para a definio das atividades, a estimativa de durao e o gerenciamento do cronograma) e outras informaes e decises sobre custos, riscos e comunicaes relacionadas com a elaborao do cronograma a partir do plano de gerenciamento do projeto. Para planejar o gerenciamento do cronograma, algumas tcnicas analticas podem ser empregas, como paralelismo ou compresso do cronograma do projeto, bem como a execuo de atividades em paralelo. As tcnicas podem incluir tambm o planejamento em ondas sucessivas, antecipaes e esperas, anlise de alternativas e mtodos de avaliao do desempenho do cronograma.
Plano de Gerenciamento dos Custos

O Plano de Gerenciamento dos Custos uma sada do processo Planejar o Gerenciamento dos Custos e descreve como os custos do projeto sero planejados, estruturados e controlados. Para o desenvolvimento deste plano so usadas informaes sobre o gerenciamento do escopo do projeto e os detalhes da Estrutura Analtica de Projeto (EAP) para a estimativa e gerenciamento dos custos. Estas informaes so obtidas do plano de gerenciamento do escopo. O termo de abertura do projeto fornece um resumo de oramento do qual os custos detalhados do projeto sero desenvolvidos. Alm disso, tambm define os requisitos de aprovao do projeto que influenciaro o gerenciamento dos custos do projeto. Os fatores ambientais da empresa tambm podem influenciar o planejamento do gerenciamento do escopo. No projeto Data Waterfall, por exemplo, o fato de algumas atividades do projeto envolverem aquisio de hardware importado, as taxas de cmbio e condies do mercado so fatores que certamente devem ser considerados no plano de gerenciamento de custos. O processo de planejar o gerenciamento dos custos pode envolver opes estratgicas para financiar o projeto, tais como autofinanciamento, financiamento com capital ou financiamento com dbito. Tambm pode detalhar maneiras de financiar os recursos do projeto, tais como execuo, aquisio, aluguel ou arrendamento. Outras tcnicas, como perodo de reembolso, retorno sobre o investimento, taxa interna de retorno, fluxo de caixa descontado, e valor presente lquido tambm devem ser consideradas.
Plano de Gerenciamento dos Recursos Humanos

O Plano de Gerenciamento dos Recursos Humanos uma sada do processo Planejar o Gerenciamento dos Recursos Humanos e descreve como os recursos humanos do projeto devem ser definidos, mobilizados, gerenciados e, por fim, liberados. Este processo responsvel por estabelecer papis, responsabilidades e organogramas do projeto, alm do plano de gerenciamento de pessoal, incluindo o cronograma para mobilizao e liberao de pessoal. Os Requisitos de Recursos das Atividades so usados para determinar as necessidades de recursos humanos do projeto.
43 | CaptuLo 4
Organogramas e Descries de Cargos so usados para documentar os papis e responsabilidades dos membros da equipe. Geralmente, os formatos correspondem a um dos trs tipos: Grficos Hierrquicos: estrutura tradicional que pode ser usada para mostrar posies e relaes em um formato grfico de cima para baixo. Um exemplo de sua aplicao seria na estrutura analtica do projeto (EAP). Grficos Matriciais (ou matriz de responsabilidades): trata-se de uma tabela que mostra os recursos do projeto alocados a cada pacote de trabalho. usada para ilustrar as conexes entre pacotes de trabalho ou atividades e os membros da equipe do projeto. Em projetos maiores, podem ser desenvolvidas em vrios nveis. O grfico RACI um exemplo de matriz de responsabilidades. Formatos de texto: til quando as responsabilidades de membros da equipe requerem descries detalhadas. Normalmente em forma de uma lista organizada ou formulrio, esses documentos fornecem informaes como responsabilidades, autoridade, competncia e qualificaes. Um nome comum para este tipo de documento descries de cargo (em ingls, job description).
Plano de Gerenciamento das Comunicaes

O Plano de Gerenciamento das Comunicaes uma sada do processo Planejar o Gerenciamento das Comunicaes e descreve como as comunicaes do projeto sero planejadas, estruturadas, monitoradas e controladas. Os fatores ambientais da empresa esto estreitamente vinculados a este processo, j que a estrutura da organizao ter um efeito importante nos requisitos de comunicaes do projeto. Como tcnicas e ferramentas para o desenvolvimento deste plano incluem-se a anlise de requisitos, tecnologias, modelos e mtodos de comunicao.
Plano de Comunicao do Projeto

A falta de comunicao apontada como o principal problema nos projetos, segundo o relatrio PMsurvey 2012. Como forma de evitar o mesmo erro, procure seguir algumas dicas simples: 1. C uidado com a linguagem corporal. Muitas vezes voc est falando uma coisa e seu corpo est reagindo ao contrario. Isso pode gerar resistncia do seu interlocutor. 2. C uidado com mensagens escritas, principalmente por e-mail. Use com moderao, de preferncia apenas para formalizaes e comunicaes em massa. Sempre que possvel comunique-se pessoalmente ou por telefone. 3. O ua. E oua ativamente. Se no puder atender a pessoa, diga isso e pea que volte em outro horrio. Assim voc mantm as expectativas alinhadas e no gera frustraes. 4. C omprove o entendimento. Comunicao entre dois indivduos diferentes um desafio, cada um interpreta de uma maneira. Garantir um bom entendimento de todos critrio crucial de sucesso. 5. S aiba lidar com conflitos. Eles sero inevitveis. 6. Ao final de cada reunio ou discusso, sumarize e recapitule os principais pontos discutidos, assim todos sabero o resultado da reunio, quem saiu com responsabilidades e quais so os prximos passos.
Plano de Gerenciamento dos Riscos

O Plano de Gerenciamento dos Riscos o resultado/sada deste processo e descreve como as atividades de gerenciamento dos riscos sero estruturadas e executadas. As atitudes, limites e tolerncia em relao aos riscos que descrevem o grau de risco que uma organizao pode suportar so fatores ambientais da empresa que podem (e certamente o faro) influenciar o plano de gerenciamento dos riscos.
44 | CaptuLo 4
As tcnicas analticas so usadas para a compreenso e definio do contexto geral de gerenciamento dos riscos do projeto, que baseado em uma combinao de atitudes das partes em relao ao risco e a exposio ao risco de um determinado projeto com base no contexto geral do projeto.
Plano de Gerenciamento das Partes Interessadas

O Plano de Gerenciamento das Partes Interessadas uma sada do processo Planejar o Gerenciamento das Partes Interessadas (que conforme visto anteriormente, um processo adicionado na quinta edio do guia PMBOK) e identifica as estratgias de gerenciamento necessrias para estimular o engajamento das partes interessadas. Alm dos dados reunidos no registro das partes interessadas, o plano geralmente fornece: Nveis de engajamento desejados e atuais das principais partes interessadas; mbito e impacto da mudana nas partes interessadas; Inter-relacionamentos identificados e potencial sobreposio entre as partes interessadas; Mtodo para atualizar e refinar o plano de gerenciamento das partes interessadas medida que o projeto progride e se desenvolve. O registro das partes interessadas, que fornece informaes necessrias para planejar maneiras apropriadas de engajar as partes interessadas no projeto. No inicio de um projeto, pode ser necessrio que as partes interessadas seniores estejam altamente engajadas, para remover quaisquer possveis obstculos com xito. A remoo bem sucedida destes obstculos pode influenciar o engajamento de outras partes interessadas, como usurios, que podem tornar-se mais importantes. Tcnicas analticas tambm podem ser utilizadas para comparar o nvel de engajamento atual de todas as partes interessadas com os nveis de envolvimento planejados requeridos para a concluso bem sucedida do projeto.
Plano de Gerenciamento da Qualidade

O Plano de Gerenciamento da Qualidade uma sada do processo Planejar o Gerenciamento da Qualidade e descreve como as polticas de qualidade de uma organizao sero implementadas. O estilo e detalhes do plano devem ser determinados pelos requisitos do projeto, que podem incluir foco mais agudo na proposio de valor, redues de custo ou frequncia de atrasos do cronograma. O plano tambm descreve como a equipe de gerenciamento do projeto planeja cumprir os requisitos de qualidade estabelecidos para o projeto. Os requisitos de qualidade oriundos da documentao dos requisitos podem ser usados pela equipe do projeto para planejar como o controle da qualidade ser implementado no projeto. Os fatores ambientais da empresa tambm podem influenciar o planejamento do gerenciamento da qualidade. Tomando como exemplo o projeto Data Waterfall, h fatores relevantes, como a pretenso em obter as certificaes ISO20000, ISO270000 e TIER III, que so normas e padres internacionais que certamente iro influenciar a cultura organizacional. O processo Planejar o Gerenciamento da Qualidade gera outras trs sadas, alm do plano de gerenciamento da qualidade: O plano de melhorias no processo. Assim como todos os planos de gerenciamento o plano de melhorias no processo tambm um plano auxiliar do plano de gerenciamento do projeto. Ele detalha as etapas de anlise dos processos de gerenciamento de projetos e desenvolvimento de produtos para identificar as atividades que aumentam o seu valor. Mtricas de Qualidade. Descrevem especificamente um atributo de projeto ou produto e como o processo de controle da qualidade o medir. Listas de verificao da qualidade. Trata-se de uma ferramenta estruturada, geralmente especfica, usada para verificar se um conjunto de etapas necessrias foi executado.
45 | CaptuLo 4
Plano de Gerenciamento das Aquisies

O plano de gerenciamento das aquisies uma sada do processo Planejar o Gerenciamento das Aquisies e descreve como a equipe do projeto deve adquirir produtos e servios fora da organizao executora. O plano tambm descreve como os processos de aquisio sero gerenciados, do desenvolvimento dos documentos de aquisies ao fechamento do contrato. O processo Planejar o Gerenciamento das Aquisies gera outras cinco sadas, alm do plano de gerenciamento das aquisies: Especificao do Trabalho das Aquisies, que desenvolvida a partir da linha de base do escopo do projeto e define apenas a parte do escopo do projeto que deve ser includa no contrato correspondente; Documentos de Aquisio, que so usados para solicitar propostas dos fornecedores em potencial; Critrios de seleo de fontes, que em geral so includos nos documentos de solicitao de aquisies. Estes critrios so desenvolvidos e usados para classificar ou avaliar as propostas dos fornecedores. Podem ser objetivos ou subjetivos. Obs: Para ilustrar, voc pode imaginar as sadas citadas acima como elementos de uma RFP (Request for Proposal). Decises de Fazer ou Comprar. Processos referentes tomada de decises (seja essa fazer internamente, ou comprar de um fornecedor externo). Solicitaes de Mudana. Decises que envolvam a aquisio de mercadorias, servios ou recursos, ou outras decises durante o planejamento das aquisies que possam gerar solicitaes de mudana, que so processadas para reviso e disposio atravs do processo Realizar o Controle Integrado de Mudanas.
Concluso
Assumindo que o planejamento antecipado, de como o projeto ser planejado, gerenciado e controlado, sempre estar em um plano de gerenciamento, fica mais fcil compreender cada um destes planos. Uma vez concludos os planos de gerenciamento do projeto, a sequncia natural seria planejar - de fato - o projeto, usando como referncia todos os planos de gerenciamento criados. Os processos de planejamentos subsequentes sero descritos a partir de agora.
Coletando Requisitos do Projeto

O primeiro passo do planejamento do projeto coletar os seus requisitos. Neste processo sero definidas e documentadas as necessidades das partes interessadas, incluindo cada entrega necessria para cumprir os objetivos do projeto. Para isso ser necessrio consultar: O Termo de Abertura do Projeto (gerado no incio do projeto), para saber o contexto geral do projeto; O Plano de Gerenciamento das Partes Interessadas, para saber quais partes interessadas devem ser consultadas para a coleta de requisitos e qual a abordagem apropriada para cada uma delas. O PMBoK sugere algumas ferramentas e tcnicas para realizao da coleta de requisitos como: Entrevistas. So aplicados questionrios para cada uma das partes interessadas. Normalmente so individuais. Focus Group. Similar entrevista, porm realizado com um grupo de partes interessadas especializadas. Um Moderador deve direcionar o grupo para discusses interativas. Workshop. Trata-se de uma reunio orientada com atividades pr-definidas com um grupo de partes interessadas multidisciplinar para que sejam coletados os requisitos. Pela caracterstica multidisciplinar, a conciliao de requisitos conflitantes acelerada. Por exemplo, um workshop promovido para desenvolvedores e os usurios do sistema.
46 | CaptuLo 4
Ferramentas de Criatividade em Grupo, como brainstorming, onde voc orienta o grupo de participantes a interagir livremente, sugerindo ideias. A regra geral que toda ideia vlida, e a princpio ningum critica a ideia de ningum. Tcnica Delphi. Um grupo de especialistas responde a um questionrio pr-estabelecido e posteriormente promovem feedback das respostas dos demais e melhoram as suas respostas a cada rodada. Isso feito em anonimato e uma boa tcnica para conseguir consenso geral. Mapa Mental. Outra excelente ferramenta para coleta de requisitos onde criada uma teia de ideias categorizadas para melhorar a visualizao dos contedos. As ideias podem ser coletadas em uma reunio de brainstorming e a partir da pode ser criado um mapa mental com o resultado. Faa uma busca no Google ou no Youtube sobre mapa mental ou mindmap e voc encontrar vasto material sobre como criar mapas mentais. T cnicas de Deciso em Grupo. Simplesmente a realizao de uma votao para decidir itens que ainda esto em conflito. Observao ou Job Shadowing. Tcnica que consiste em, literalmente, observar algum enquanto a pessoa executa suas atividades no dia a dia e tomar nota de tudo que acontece. Muitas vezes esta a melhor forma de saber de verdade qual a necessidade da parte interessada. Desenvolvimento de um Prottipo. Outra tcnica bastante efetiva para coletar requisitos. Muitas vezes a parte interessada no sabe que precisa de uma determinada funcionalidade at que utilize a soluo em questo. A coleta de requisitos tambm pode ser acelerada atravs de questionrios e pesquisas. Desta forma possvel impactar um grupo grande de partes interessadas, que por outros meios poderiam ser demoradas e at mesmo inviveis. Como sada para este processo, temos a documentao de requisitos do projeto. Este documento pode incluir: As necessidades de negcio Necessidades funcionais Tcnicas Requisitos de qualidade Critrio de aceitao das entregas Impacto em outras reas Premissas e restries que forem identificadas durante a coleta de requisitos
Definindo o Escopo do Projeto

O segundo passo do planejamento do escopo : Definir o Escopo. Neste processo ser desenvolvida a descrio detalhada do projeto e do produto do projeto. O principal objetivo promover o entendimento comum do que deve ser feito. Como principal sada deste processo, temos a Declarao do Escopo do Projeto. A DEP (sigla para Declarao do Escopo do Projeto), que inclui: A descrio do escopo do produto do projeto, Os critrios de aceitao do produto, As entregas do projeto, As excluses do projeto, ou seja, o que no est contido no escopo, As restries do projeto, que podem ser restries de tempo, custo, tecnologia, recurso, diretrizes, etc. As premissas do projeto (que so fatores assumidos como verdadeiros)
47 | CaptuLo 4
Premissas e Restries
Neste momento vale a pena abrir um parntese para discutir os conceitos de premissas e restries, que sempre geram um pouco de confuso. Restries so fatores que delimitam algo no projeto. So fatos. Por exemplo, o projeto no pode estender o prazo de 14 de fevereiro. uma imposio. Premissa um fator que voc assume como verdade para que possa evoluir com o planejamento, ainda que seja uma incerteza. Por exemplo, premissa do projeto que a equipe de desenvolvimento possa realizar horas extras. Se esta premissa no for cumprida ao longo do seu projeto, voc pode ter um problema, pois planejou o escopo, custo e demais fatores considerando as premissas estabelecidas. Voc as assumiu como verdade. Toda premissa gera um risco, que deve ser mapeado durante o processo de identificao de riscos e ser includo no plano de resposta ao risco. Se alguma premissa no for cumprida, haver uma resposta apropriada para reverter ou mitigar os impactos de um risco que de fato aconteceu, e ainda assim o sucesso do projeto pode ser assegurado. importante ressaltar que no uma boa prtica para gerentes de projeto o ato de assumir premissas e utiliza-las futuramente como justificativa para o no cumprimento de algum requisito ou entrega do projeto. Um bom gerente de projetos antecipa problemas e trabalha sempre com as cartas na mesa.
Evite o Gold Plating

H um jargo no mundo de Gerenciamento de Projetos chamado Gold Plating. Significa banhar a ouro algo que voc no precisava, ou estava fora da especificao ou o escopo adicional sem controle de mudanas. Em vrias oportunidades voc j deve ter ouvido frases como: J que estamos fazendo tal coisa, vamos aproveitar e fazer esta outra coisa tambm. Se voc aceita isso, est praticando o Gold Plating. Por mais que voc pense que est agradando o seu cliente entregando algo a mais que no foi pedido, ou algo no previsto at a concluso do planejamento e sem um processo formal de gerenciamento de mudanas, voc est trazendo um risco para o seu projeto. Este algo a mais pode custar mais caro, trazer algum risco adicional ou demorar mais tempo.
Criando a Estrutura Analtica do Projeto (EAP)

O ultimo passo para o planejamento do escopo a criao da EAP - Estrutura Analtica do Projeto, tambm conhecida pelo termo em ingls WBS - Work Breakdown Structure. A EAP uma decomposio do escopo do projeto em nveis hierrquicos, sendo eles: Projeto, no nvel mais alto, seguido por fases (se o projeto tiver fases distintas), depois o produto ou entrega do projeto e por fim os pacotes de trabalho. Dentre algumas das caractersticas da EAP, podemos citar que: orientada a entregas. Ou seja, as atividades no so listadas ou detalhadas na EAP. A ttulo de curiosidade, este o motivo pelo qual o nome dos pacotes de trabalho so sempre substantivos e nunca verbos; Serve para deixar claro, de forma visual, tudo que ser entregue pelo projeto e como isto esta organizado; Tambm til para delegar responsveis por cada entrega. A principal tcnica utilizada para criar a EAP decomposio. Por meio desta tcnica o projeto ser decomposto em produtos e, entregas e pacotes de trabalho que sejam mais fceis de serem gerenciados. A EAP deve ser decomposta at o nvel apropriado para definir um responsvel, estimar o tempo e custo do pacote de trabalho. Como ferramenta visual a EAP melhora a comunicao do projeto, e a decomposio do projeto at o nvel onde possvel estabelecer um responsvel influencia o comprometimento dos envolvidos e evita a omisso de entregas.
48 | CaptuLo 4
Por conta do natural nvel de incerteza no inicio do projeto, provavelmente ser necessria a atualizao deste documento em algum momento. As atualizaes na EAP no so indesejveis, desde que sigam um processo formal de mudana de escopo. Com a concluso da EAP gera-se a linha de base de escopo do projeto, tambm conhecido como baseline de escopo. A linha de base formada por: Declarao do escopo do projeto (que uma sada do processo Definir Escopo visto anteriormente); A EAP propriamente dita; O dicionrio da EAP, que um documento que d suporte a EAP, trazendo informaes detalhadas sobre entregas, atividades e agendamento de cada componente da EAP. A linha de base do escopo a formalizao final das entregas do projeto. E o que mais importante, nada alm destas entregas (lembre-se do Gold Plating). A partir dai qualquer mudana no plano do projeto, que afete a linha de base, deve passar por um processo de gerenciamento de mudana. Existem diversas ferramentas no mercado para construo de EAP. A WBS Chart Pro uma ferramenta que pode ser utilizada gratuitamente para at 50 pacotes de trabalho. Alm disso, ela se integra ao Microsoft Project. Vale a pena conhecer.
Definindo as Atividades do Projeto

Neste processo sero identificadas as aes especificas que devem ser desenvolvidas para produzir as entregas do projeto. O pacote de trabalho definido na EAP deve ser usado como referncia para determinar estas atividades. Aqui ainda no existe a preocupao de sequenciar as atividades cronologicamente. Elas sero apenas listadas. Normalmente criamos essa lista de atividades sequencialmente em ferramentas como o Microsoft Project, ento natural pensarmos em ordem cronolgica. Isto deve ser feito para todos os pacotes de trabalho. Como recomendao, voc pode criar a EAP no WBS Chart Pro, exportar para o Microsoft Project e iniciar a lista de atividades por l.
49 | CaptuLo 4
Sequenciando as Atividades do Projeto

Durante este processo o relacionamento entre as atividades do projeto devem ser identificados e documentados. O primeiro modelo de relacionamento entre atividades o modelo trmino - inicio. Neste deve-se necessariamente finalizar a primeira atividade para iniciar a segunda.
No exemplo acima, voc deve elaborar o material para posteriormente publica-lo. No grfico de Gantt (aquele grfico com barras laterais que aparecem na janela direita do Microsoft Project quando se cria um cronograma) este relacionamento representado com uma seta para baixo. Quando este relacionamento mapeado no cronograma da forma correta, voc tem uma viso realista do prazo final do projeto permitindo tambm um controle realista. Imagine um projeto com duas atividades simples, que estejam relacionadas no cronograma: Atividade 1: Reformar a parede. Atividade 2: Pintar a parede. Se o tempo da atividade 1 for alterado, automaticamente ela empurra o inicio da atividade 2 para frente. Isso pode mudar o prazo final do seu projeto, caso esta atividade estiver no caminho critico. Vamos aprender sobre caminho critico mais a frente. O segundo modelo de relacionamento o inicio inicio. Neste tipo de relacionamento, as atividades devem iniciar impreterivelmente ao mesmo tempo, mas no necessariamente acabam ao mesmo tempo. Por exemplo, se o prazo final da atividade 1 for alterado, no necessariamente o prazo final da atividade 2 ser alterado. Mas se o incio da atividade 1 for alterado, o inicio da atividade 2 tambm ser alterado. Imagine as seguintes atividades relacionadas: Atividade 1: Realizar reunio para coleta de requisitos. Atividade 2: Documentar requisitos. A documentao de requisitos depende da reunio. Portanto, o modelo inicio - inicio o relacionamento adequado para este caso. No relacionamento Inicio - Trmino, a data de inicio da atividade 2 delimita a data de trmino da atividade 1. Imagine estas outras atividades: Atividade 1: Estudar para a prova. Atividade 2: Realizar a prova (que j est agendada). Neste caso, a prova j esta agendada, ento no se pode mudar o inicio desta atividade postergando o final da atividade 1.
50 | CaptuLo 4
E finalmente, no relacionamento Trmino Trmino, a concluso da atividade 1 delimita a concluso da atividade 2. Ou seja, as duas necessariamente terminaro juntas. Imagine as seguintes atividades: Atividade 1: Implantar uma soluo. Atividade 2: Monitorar o andamento da implantao. Quando a implantao for concluda voc no ter mais o que monitorar. Portanto o modelo trmino - trmino o mais adequado.
Determinao de Dependncias
As dependncias entre atividades podem ser de trs tipos: Obrigatrias. Ex.: Voc precisa escrever um artigo antes de publica-lo. Arbitrrias. So representadas por uma boa prtica. Ex.: melhor voc pintar as paredes antes de colocar o carpete. Mas se no der tempo, voc pode realizar as duas atividades em paralelo, com o risco de manchar o tapete, ou afetar a qualidade de uma entrega. Externas. Quando depende de fatores externos e fora do controle do projeto.
Lag (Espera) e Leads (Antecipao)

Outra tcnica utilizada no sequenciamento a Espera ou Antecipao. Em um relacionamento inicio - inicio, o lag (espera) pode ser utilizado caso seja necessrio aguardar um perodo at que a atividade 2 inicie.
Na figura acima, a monitorao do indicador do prottipo possui um lag de 15 dias, ou seja, deve ser iniciada 15 dias aps a implantao do prottipo. Caso a implantao do prottipo seja postergada, a monitorao do indicador tambm ser postergada por 10 dias, alm dos 15 dias referentes ao lag. No Microsoft Project o lag representado por um sinal de mais (+) seguido pelo numero de dias de espera ao lado do tipo de relacionamento. J em um relacionamento trmino - inicio, a atividade 2 deve iniciar X dias depois do trmino da atividade 1. No exemplo da figura possvel ver que ser necessrio aguardar 2 dias (lag) para aplicar a segunda mo de tinta. Este lag foi definido para garantir que, independente de quando for iniciada a pintura da parede, haja um perodo de dois dias aps a primeira mo para que d tempo suficiente de secar a pintura. Um lead utilizado para antecipar uma atividade. Por exemplo, uma equipe a ser contratada em breve precisa ser treinada no primeiro dia de trabalho. Para isso, o planejamento do treinamento deve ser feito 5 dias antes do prazo final para a contratao da equipe.
51 | CaptuLo 4
Diagrama de Rede
Um diagrama de rede a representao do sequenciamento das atividades atravs de um diagrama. Veja um exemplo a seguir:
No exemplo, a atividade 3 depende da atividade 1, a atividade 4 depende da atividade 3 e a atividade 5 depende da concluso das atividades 1 e 2. Provavelmente voc no ir desenhar um diagrama de redes na gesto dos seus projetos no dia a dia, mas importante que conhea o conceito para entender o caminho critico que veremos mais a frente.
Estimando os Recursos das Atividades do Projeto

Durante este processo so estimados o tipo e quantidade de recursos, material, pessoas, equipamentos e suplementos para realizao das atividades. preciso saber quais recursos esto disponveis e que sero alocados no projeto para pode estimar a durao das atividades. Tenha cautela ao estimar os recursos das atividades de um projeto. Adicionar muitos recursos a uma atividade com objetivo de termina-la mais rpido nem sempre vai funcionar. H uma curva de aprendizado que deve ser considerada, e respeitada. Do conhecimento popular: uma gestante d a luz em nove meses, mas nove gestantes no do a luz em um ms.
Estimando a Durao das Atividades do Projeto

O objetivo agora estimar a durao das atividades. Para isso, ser necessrio consultar: O calendrio dos recursos disponveis; As restries e premissas de prazo ou de recursos que possam afetar a estimativa de alguma forma; Informaes histricas de atividades similares de projetos passados, que podem servir de referncia para a estimativa de durao das atividades; Os riscos do projeto, que podem direcionar a necessidade de uma reserva de contingencia; A lista de atividades e a declarao de escopo do projeto. importante reforar que no o gerente de projetos quem define a durao das atividades. Os especialistas nas atividades quem tem o gabarito tcnico para poder estimar a durao. Existem diversas tcnicas que facilitam o trabalho de estimar a durao das atividades. Uma delas a estimativa anloga, onde so considerados parmetros como tamanho, prazo, recursos envolvidos e oramento disponvel de projetos similares para estimar o tempo das atividades. Esta tcnica considerada mais barata e rpida, mas tambm menos precisa. Na estimativa paramtrica, utilizam-se estatsticas de relacionamento de atividades de projetos anteriores para determinar a durao das atividades (ex.: tempo de trabalho por metro quadrado, ou linhas de cdigo de programa por jornada de trabalho). Na estimativa de trs pontos, leva-se em considerao a estimativa mais provvel (considerando expectativas, produtividade dos recursos, dependncias, etc.), a estimativa mais otimista (o melhor cenrio de execuo) e a estimativa mais pessimista (o pior cenrio de execuo).
52 | CaptuLo 4
Calcula-se ento uma mdia balanceada das trs estimativas para obter o prazo esperado. Outro recurso importante, mas que deve ser utilizado com cautela o buffer de tempo da atividade. O buffer de tempo uma reserva de contingencia planejada para compensar riscos do projeto. Diferentemente da famosa gordurinha que se costuma incluir nas estimativas de tempo para ter uma folga de prazo maior, o buffer de tempo deve ser documentado claramente, por exemplo, com nome reserva de contingencia para os riscos xyz.
O buffer pode ser adicionado a uma atividade especifica ou ao prazo final do projeto e o gerente de projetos tem autonomia para utilizar esta reserva, reduzi-la ou at mesmo elimin-la.
Desenvolvendo o Cronograma do Projeto

O cronograma do projeto a consolidao das atividades sequenciadas, recursos alocados e a estimativa de durao das atividades. A partir do cronograma concludo, tem-se o baseline de tempo do projeto. Em outras palavras, significa que o cronograma est oficialmente definido, e a partir deste momento qualquer alterao nele deve ser feita atravs de um processo formal de gerenciamento de mudanas. Existem algumas ferramentas e tcnicas que podem potencializar os benefcios e vantagens de se criar um cronograma do projeto, transformando-o em um verdadeiro canivete suo.
Milestones
O milestone define um ponto de controle, e geralmente utilizado para representar uma entrega do projeto. No Microsoft Project quando uma atividade atribuda com a durao 0 (zero), automaticamente o Project marca aquela atividade como um milestone. A simbologia de um milestone representada por um losango, conforme a figura abaixo:
53 | CaptuLo 4
Caminho Critico do Projeto

Em um captulo anterior, voc aprendeu que diagrama de rede usado para sequenciar as atividades. O caminho crtico do projeto definido como o caminho mais longo do diagrama de rede. Ou seja, ele define o prazo final do projeto. O termo crtico justificvel, pois qualquer atraso nas atividades do caminho crtico gera atraso na concluso do projeto. Alm disso, pode haver mais de um caminho critico em um projeto.
No exemplo acima, considerando que: A atividade B depende da concluso da atividade A A atividade F depende da concluso das atividades A e E A atividade C depende da concluso da atividade B A atividade D depende da concluso da atividade C. Qual o prazo final deste projeto? Qual o caminho critico? Para descobrir, voc precisa somar a durao das atividades para estipular o prazo final do projeto e avaliar qual dos dois caminhos tem o maior prazo de concluso. Neste caso, a resposta = A+F. Soma-se 25 dias da atividade A com 30 dias da atividade F, totalizando o maior prazo do projeto: 55 dias. Se voc sequenciou as atividade da forma correta, o caminho crtico do projeto apresenta as atividades que o gerente de projetos dever tomar mais cuidado para que no atrasem, caso queira cumprir com o cronograma do projeto. Eu j vi muitos projetos irem por agua abaixo por um mal sequenciamento de atividades e um controle falho do caminho crtico. No Microsoft Project existe uma viso do diagrama de Gantt que apresenta o caminho crtico do projeto.
Tcnicas de Reduo do Cronograma

Para reduzir o cronograma, necessrio se concentrar nas atividades do caminho critico, afinal elas que determinam o maior tempo para concluso do projeto. A primeira tcnica que pode ser utilizada Compresso ou Crashing da atividade. Nesta tcnica a durao da atividade reduzida com a adio de mais recursos.
Ao usar essa tcnica, considere os seguintes pontos de observao: Pode haver aumento do custo do projeto (mais recursos, mais custos); Curva de aprendizado, citada anteriormente como preocupao quando se tenta adicionar mais recursos com o objetivo de diminuir o tempo de uma atividade. A segunda tcnica o paralelismo ou o famoso Fast Tracking. Se voc leu o primeiro captulo desta obra deve se lembrar de que esta tcnica foi utilizada no projeto de construo do Empire State Building.
54 | CaptuLo 4
A tcnica do paralelismo consiste em realizar paralelamente atividades que seriam feitas sequencialmente por questo de boa pratica, ou seja, com relacionamento sequencial arbitrrio. Neste caso, o principal risco a perda de qualidade.
Estimando os Custos do Projeto

A estimativa dos custos de um projeto deve considerar todos os esforos necessrios para terminar o projeto, desde os esforos para realizar o gerenciamento do projeto at os custos associados diretamente ao projeto, como mo de obra, materiais, treinamento, computadores, etc. Voc pode utilizar as mesmas ferramentas que vimos em estimativa de prazo para estimar os custos, (Anloga, paramtrica e de Trs Pontos). A estimativa deve ser feita de acordo com os mtodos definidos no plano de gerenciamento de custos e baseada nos detalhes do que se est estimando, como por exemplo, o que est fora do escopo e quais so as restries impostas ao projeto. H diversas formas de analisar os custos durante uma estimativa. Basicamente os custos podem ser: Variveis. Quando mudam de acordo com a quantidade de produo ou de trabalho. Ex.: custos de materiais, suprimentos, salrios, etc.; Fixos. Quando no mudam com mudanas na produo. Ex.: custo de instalao, aluguel, utilidades, etc.; Diretos. Quando so diretamente atribuveis ao trabalho no projeto. Ex.: viagens, salrios da equipe; Indiretos. Quando incluem itens de despesas administrativas ou custos incorridos para benefcio de mais de um projeto. Ex.: impostos, servios bsicos como gua, luz, telefone. Para concluir o baseline de custo do projeto, o gerente de projetos adiciona uma reserva de contingencia, que deve sempre estar atrelada a algum risco do projeto, estimativa de custo.
Determinando o Oramento do Projeto

O custo total do projeto deve ser calculado para determinar o montante de fundos que a organizao precisa ter para financiar o projeto. O resultado deste clculo o que conhecemos por oramento. A linha de base de custos a parte do oramento que ficar sob o controle do gerente de projetos, e cumpri-la ser tambm uma forma de aferir o sucesso do projeto. No se esquea que a EAP deve ser decomposta ao ponto de melhorar o gerenciamento e at que possa ser determinada a durao, o custo e o responsvel pelo pacote de trabalho. O oramento do projeto aciona uma reserva de gerenciamento ao baseline de custo do projeto. Esta reservar de gerenciamento apenas o Sponsor tem autonomia para utiliza-la e serve para cobrir riscos que no forma previstos.
Identificando os Riscos do Projeto

Riscos so passveis de aparecer a qualquer momento e normalmente causam impactos (negativos) significativos para o projeto. Por este motivo o processo de identificar riscos interativo, ocorre desde o incio at o encerramento do projeto. Os riscos identificados devem ser registrados em uma lista de forma detalhada e especfica. Por exemplo, o risco exceder o prazo no diz o que voc precisa para traar um plano de ao. Seria mais apropriado algo como Prazo exceder por falta de documentaes para consulta e estabelecimento de estimativas acuradas. Quanto mais riscos voc identificar melhor, mas tenha cuidado com o micro gerenciamento. Considere sempre os riscos que possam ser relevantes ao contexto do projeto. FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO
55 | CaptuLo 4
Realizando a Anlise Qualitativa dos Riscos do Projeto

O segundo passo com relao aos riscos do projeto fazer a anlise qualitativa dos riscos. Os critrios de impacto e probabilidade para riscos so definidos no plano de gerenciamento de riscos, que voc conheceu no incio deste captulo. A partir destes critrios deve-se criar uma matriz para destacar os principais riscos do projeto, alm de enderear um plano de resposta para cada um deles. Como boa prtica de gerenciamento de riscos, costuma-se considerar que para os riscos com mdia/alta probabilidade e impacto deve haver necessariamente um plano de resposta. E para os riscos de menor probabilidade e impacto pode-se at mesmo adotar a medida de assumir o risco. O mais importante que todos os riscos sejam gerenciados de acordo com o plano de gerenciamento de riscos definido para o projeto.
Realizando a Anlise Quantitativa dos Riscos do Projeto

A anlise quantitativa de riscos no simples de se fazer. necessrio ter informaes histricas para tal. Por conta disso, a anlise deve ser feita apenas para os principais riscos, dos quais haja informaes suficientes. Uma analise quantitativa dos riscos pode enderear decises importantes que poderiam ser feitas de forma equivocada sem a anlise. Por exemplo, voc precisa ter informaes estatsticas concretas da probabilidade de algum evento ocorrer para poder calcular o impacto do daquele risco.
Planejando Resposta aos Riscos do Projeto

O ultimo passo para o planejamento do risco, e no menos importante, planejar resposta aos riscos. Neste processo sero desenvolvidas opes e aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto. De posse da lista de riscos mapeados, categorizados e avaliados qualitativamente, j possvel saber quais so os riscos mais crticos que devero ter uma ao de resposta. As aes de resposta aos riscos mais comuns so: T ransferir o risco. Significa transferir o impacto do risco a um terceiro. Ex.: repassar ao fornecedor externo o valor da multa em caso de atraso. A ceitar o risco. Quando o risco tolervel e/ou quando ao de resposta no justificvel sob o ponto de vista de custo ou prazo, pode-se aceitar ativamente ou passivamente o risco. Aceitando um risco ativamente, ser adicionada ao menos uma reserva de contingencia ao baseline de tempo ou ao baseline de custo do projeto. Aceitar passivamente um risco significa apenas monitora-lo. Esta atitude deve ser utilizada somente se todas as outras possibilidades j tiverem sido esgotadas. Mitigar o risco. Significa reduzir o impacto ou a probabilidade dele acontecer. Neste caso o plano de resposta ser traar aes para tentar impedir que o risco acontea. Ex.: contratar seguranas para vigiar uma obra em construo durante a madrugada, evitando o risco de roubo de materiais. Eliminar o risco. Significa aplicar uma ao que ir eliminar definitivamente o risco. Ressalto que um gerente de projetos competente e profissional est sempre trabalhando para previnir problemas futuros e no apenas lidando com problemas no presente. Para isso, uma boa gesto de riscos do projeto fundamental.
56 | CaptuLo 4
Executando o Projeto
Neste captulo o assunto execuo. Voc saber como: Orientar, mobilizar e gerenciar a equipe do projeto; Garantir a qualidade, conduzir as aquisies; Distribuir as informaes do projeto; Gerenciar as expectativas das partes interessadas. O estgio de execuo responsvel por completar o trabalho definido no plano de gerenciamento do projeto.
Orientando e Gerenciamento a Execuo do Projeto

Uma das principais preocupaes durante o estgio de execuo integrar todos os trabalhos de execuo em um esforo coordenado para cumprir o plano de gerenciamento do projeto e produzir as entregas definidas. De forma mais detalhada, isso inclui, por exemplo: Atualizar o plano do projeto, adicionando novos riscos e melhorias de processos identificadas conforme a evoluo do projeto; Atualizar o plano de RH conforme membros entram e saem do projeto; Atualizar os documentos de escopo, tempo e custo, caso haja alguma mudana aprovada para estes itens. As atualizaes em planos, apesar de no parecerem muito coerentes com uma fase que se preocupa em executar o que j foi planejado, faz todo sentido. Como visto anteriormente, existem diversas variveis que podem influenciar o planejamento de um projeto, mesmo durante sua execuo. O termo Rolling Wave Planning muito usado na disciplina de gerenciamento de projetos, e significa realizar o planejamento em ondas sucessivas. Ou seja, mudanas no baseline do projeto ou nos planos de gerenciamento so inevitveis. Estas mudanas no devem ser consideradas como indesejveis, pois podem trazer um resultado ainda melhor para o projeto. Contudo, o gerente de projetos precisa garantir que estas mudanas sejam controladas, por meio do processo apropriado para gerenciar mudanas. O processo de orientar e gerenciar o trabalho do projeto envolve, acima de tudo, o gerenciamento de pessoas para mant-las engajadas no projeto, realizando o trabalho e melhorando os processos envolvidos no trabalho. O gerente de projetos responsvel por ajudar a equipe a finalizar o trabalho, e garantir uma compreenso comum do projeto entre as partes interessadas.
Mobilizando a Equipe do Projeto

Mais uma vez um sinal de possvel incoerncia. Voc deve estar se perguntando: Se todo o planejamento do projeto j foi feito, porque s agora a equipe de projeto ser mobilizada? Na verdade, a mobilizao da equipe j comeou l no incio do projeto, quando a opinio de especialistas foi necessria para apoiar a elaborao do termo de abertura do projeto. Mas comum, principalmente em grandes projetos, que parte das pessoas seja envolvida um pouco antes do incio dos trabalhos (execuo), por exemplo, fornecedores externos, ou profissionais temporrios especializados (custo alto da hora de trabalho) que sero contratados para a realizao de entregas especficas. Lembre que eu mostrei la atrs que o processo de gerenciamento de projetos no linear. A realizao de processos se sobrepe. Voc ir utilizar inclusive sadas deste processo para planejar o cronograma do projeto, como o calendrio dos recursos disponveis, por exemplo.
57 | CaptuLo 4
Considere as seguintes atividades como importantes neste processo: Saber quais os recursos que foram designados para o projeto e confirmar sua disponibilidade; Negociar para obter os melhores recursos possveis; Contratar novos funcionrios; Terceirizar; Gerenciar riscos associados indisponibilidade dos recursos; Gerenciar as disputas de carga de trabalho da equipe (atividades do projeto X atividades do dia a dia). Como resultado, gera-se a lista da equipe do projeto e o calendrio dos recursos. Este documento contm informaes dos recursos, como rea, funo, nome, contato e calendrio.
Desenvolvendo a Equipe do Projeto

O desenvolvimento da equipe do projeto lida com a questo de melhorar o desempenho da equipe e do trabalho da equipe. Para isso, h um leque de opes. Organizao de treinamentos para aprimorar as competncias da equipe. Estes treinamentos podem ser formais ou informais. Uma boa prtica, por exemplo, pedir aos membros mais experientes da equipe replicar o conhecimento para outros membros. Quando orar custos para treinamento, procure interpretar como um custo da conformidade de qualidade do projeto. Os custos da no conformidade certamente sero sempre maiores e mais negativos ao projeto. Coaching com os membros da equipe. Visando melhorar competncias que foram identificadas como ponto de melhoria em um profissional. Construo do espirito de equipe (team building). A comunicao entre os participantes de um projeto deve ser sempre estimulada. Podem-se realizar atividades como dinmicas de grupo, workshops ou sees de brainstorming. A criao de materiais em conjunto tambm pode ajudar na construo do esprito de equipe. Estabelecer uma war room. uma maneira de alocar os recursos do projeto juntos, em uma mesma sala de preferncia, dividindo a mesma mesa, se preciso. Quanto maior a imerso da equipe, mais rpido sero os resultados. Est tcnica muito utilizada em momentos de crise, de qualquer natureza, justamente pela agilidade do processo. Scrum Meetings. Outro recurso que garante o alinhamento. Todos saem da reunio buscando o objetivo comum. Em uma scrum meeting junta-se os membros da equipe para passar rapidamente as atividades do dia. uma reunio rpida, de no mximo quinze minutos, e todos saem dali sabendo o que esperado deles no final do dia. Alm disso, importante promover atividades extracurriculares, como happy hour, eventos externos e outras formas de diverso.
Gerenciando a Equipe do Projeto

Assim como o desenvolvimento da equipe do projeto, o gerenciamento da equipe do projeto feito durante a execuo do projeto. Uma das mximas da administrao e da melhoria contnua de processos diz que O que no medido no gerenciado. Portanto, uma das maneiras mais eficazes de gerenciar a equipe do projeto documentando o desempenho dela. Pense em um recurso alocado no projeto Data Waterfall. O desempenho dele quanto a realizao dos trabalhos sob sua responsabilidade precisa ser documentado. Com isso, um relatrio deste perodo pode ser enviado ao gerente imediato deste recurso como complemento sua avaliao de desempenho geral. Este recurso est trabalhando no projeto por um perodo, mas quem ir promov-lo, aprovar frias e aumento da sua remunerao salarial o seu gerente funcional.
58 | CaptuLo 4
Outra maneira muito eficaz de gerenciar a equipe do projeto fornecendo feedback constante, seja positivo ou construtivo. Termos negativistas como pontos negativos, deficincia, baixo desempenho devem ser evitados a todo custo para evitar a desmotivao da equipe. Considere sempre qualquer fraqueza como uma oportunidade de melhoria. Quando possvel, use a estratgia do sanduiche nas sesses de feedback. Esta estratgia consiste em iniciar a sesso com um feedback positivo, seguido por um construtivo e por fim outro positivo. Isso serve para que o interlocutor no saia da sesso com uma m impresso, pensando apenas no ultimo ponto de observao comentado. Deixe o melhor para o final. Os conflitos tambm sero inevitveis, e mais uma vez o gerente de projetos deve demonstrar destreza e habilidades suficientes para gerenciar os conflitos e administrar as eventuais mudanas que sejam necessrias para aperfeioar o desempenho do projeto.
Gerenciando a Comunicao no Projeto

Durante a execuo do projeto, muitas partes interessadas precisam receber informaes sobre ele. Para isso necessrio realizar inmeras reunies e apresentaes, elaborar matrias para jornais internos ou portais, publicar informaes nas ferramentas de gerenciamento de projetos disponveis. O importante aqui garantir que as partes interessadas esto visualizando que suas necessidades esto sendo atendidas e direcionadas. De uma maneira resumida, trata-se da implementao do plano de gerenciamento das comunicaes (aquele que foi definido l no estgio de planejamento) utilizando a tecnologia, modelos e mtodos estabelecidos para satisfazer as necessidades de comunicao para o projeto. muito importante garantir que as informaes fluam em todas as direes necessrias para o projeto. Por exemplo, as partes interessadas devem ter a oportunidade de solicitar informaes e apontar alguma questo sobre o projeto sempre que necessrio.
Reunies, o Pesadelo da Equipe do Projeto

As equipes de projetos costumam considerar as reunies como verdadeiros pesadelos. Com as dicas a seguir, possvel reverter ou mitigar esta intepretao negativa sobre as reunies de projeto. No convide para a reunio quem no precisa estar nela. Deixe claro para o convidado qual a necessidade dele estar nesta reunio e o que esperado dele; Procure manter o foco da reunio e incentivar os outros membros a fazer o mesmo; Envie sempre a pauta com antecedncia e com detalhes suficientes para que os convidados saibam do que se trata a reunio; Cumpra com o horrio de inicio e fim da reunio. Respeite o seu tempo e o de seus convidados; Garanta que a sala que agendou tem todo equipamento que voc precisa; Prepare-se antes de ir para a reunio. Tenha em mente o que se espera como resultado dela; Ao final, faa um breve resumo sobre os principais pontos de deciso e os prximos passos; E no se esquea de enviar a todos a ata da reunio para formalizar o resultado.
59 | CaptuLo 4
Tcnicas de Apresentao
Aproximadamente 90% dos trabalhos do gerente de projetos so voltados para comunicao. E uma excelente forma de se comunicar atravs de apresentaes. Seguem algumas dicas para acertar em cheio e fazer apresentaes que realmente tragam valor ao projeto. Em uma apresentao presencial, quem tem que brilhar o apresentador, ento cuidado com as animaes. Utilize somente quando forem importantes para o contexto ou quando estiverem estritamente relacionadas com o que est sendo dito. Procure utilizar links mentais, figuras ou frases curtas ao invs de texto. Respeitando-se as limitaes do propsito da apresentao. Se for um material que o interlocutor utilizar para consultar sozinho, no tem como fugir de incluir os textos suficientes para que ele entenda o que est sendo apresentado. Cuidado com o dilema do meio termo, onde voc elabora uma apresentao que no tem os detalhes suficientes e ainda tem muita informao. Procure desenvolver sua apresentao em camadas. Primeiro monte o material o mais detalhado possvel, depois desenvolva uma capa resumida com os principais pontos e links para os detalhes, somente no caso de questionamentos especficos. Estas so apenas algumas dicas. Existem centenas de literaturas sobre este tema e altamente recomendvel fazer uma pesquisa mais detalhada sobre o tema.
Conduzindo as Aquisies
No estgio de execuo do projeto devem ser conduzidas, de fato, as aquisies definidas no plano de gerenciamento das aquisies (definido no estgio de planejamento). Dentre as atividades mais importantes, incluem-se o recebimento e classificao das propostas dos fornecedores, eliminao de fornecedores que no atendam aos requisitos definidos, obteno das propostas de preo e deciso pela contratao de um fornecedor, que pode ser atravs de um leilo, por exemplo.
Gerenciando o Engajamento das Partes Interessadas

Para atender s necessidades das partes interessadas, resolver suas questes e garantir que elas se mantenham interessadas e participativas no projeto essencial gerenciar seu engajamento e as expectativas. O segredo de um bom gerenciamento das partes interessadas conduzir aes proativas que enfatizem s partes interessadas o quanto suas ideias so importantes e que as suas expectativas, necessidades e preocupaes esto sendo consideradas, sempre. Pode parecer uma perda de tempo, mas estas aes incentivam o apoio da parte interessada e mantm canais de comunicao abertos. Como consequncia, podem-se ter informaes antecipadas (ou em tempo hbil para lidar com elas) sobre possveis mudanas, riscos, entre outros. Muitas vezes isso significa economizar tempo.
Realizando a Garantia da Qualidade

Realizar a garantia da qualidade, diferente do que costumamos aplicar nas empresas, significa focar na auditoria do processo para verificar se est sendo seguido o que foi estabelecido no plano de qualidade. Vejo no dia a dia as pessoas chamando o processo de planejar a qualidade de realizar a garantia da qualidade. Conforme descrito anteriormente, no estgio de planejamento do projeto desenvolvido o plano de gerenciamento da qualidade, que em linhas gerais descreve de que forma a qualidade do projeto ser monitorada, analisada, reportada e melhorada. Realizar a garantia da qualidade audita os processos na execuo para validar se o plano est sendo seguido.
60 | CaptuLo 4
Com base nas medies realizadas durante a monitorao e controle do projeto (que ser descrito em detalhes no prximo captulo) a garantia da qualidade precisa enderear questes como: Estamos tendo resultados apropriados com relao ao que foi definido sobre qualidade no plano de gerenciamento da qualidade? Estamos fazendo certo? Neste momento, podemos dizer que a qualidade planejada apropriada para atender aos requisitos do cliente? Estamos fazendo da forma certa? Podemos fazer melhor? Os processos esto sendo seguido? Esto entregando resultados como havamos? Existem diversas ferramentas de qualidade que podem subsidiar este trabalho, como auditorias da qualidade e anlises de processo. As auditorias funcionam muito bem para identificar no conformidades com relao a uma determinada inteno ou conjunto de intenes. Por exemplo, o plano de gerenciamento da qualidade um conjunto de vrias intenes relacionadas a como a qualidade do projeto deve ser endereada durante o seu ciclo de vida. A auditoria procura identificar se estas intenes esto sendo de fato cumpridas, e caso negativo, gera-se uma no conformidade. O processo se encarrega de exigir que para cada no conformidade seja desenvolvida uma ao corretiva. Outra vantagem das auditorias que normalmente so realizadas por uma equipe externa ao projeto, normalmente uma rea funcional de controle/gesto de qualidade. Isso d maior transparncia e credibilidade ao resultado da auditoria. De qualquer forma, as auditorias no devem ser consideradas, nunca, como negativas. Auditorias no buscam culpados, e sim deficincias que precisam ser corrigidas ou oportunidades de melhoria para um bem maior. As anlises de processo so esforos em busca da melhoria contnua. Imagine uma atividade que seja repetidamente executada no projeto Data Waterfall, por exemplo, a instalao de mquinas virtuais. As lies aprendidas nas primeiras instalaes podem ser usadas para aprimorar o procedimento para as prximas instalaes.
Monitorando e Controlando o Projeto

Durante a realizao de todas as atividades do projeto, desde a iniciao at o encerramento, necessrio rastrear, revisar e regular o progresso e o desempenho do projeto. Isto inclui o monitoramento e controle dos trabalhos do projeto, como riscos, entregas, mudanas, aquisies e a qualidade do projeto. O bom planejamento de um projeto, associado a um monitoramento e controle eficaz, representa 85% do caminho de um projeto bem sucedido. Os outros 15% so garantidos por meio da iniciao e encerramento apropriados e da liderana ativa da equipe durante a execuo do projeto.
Monitorando e Controlando o Trabalho do Projeto

A monitorao e o controle do trabalho do projeto consistem em obter e comparar dados de desempenho reais do projeto com os dados de desempenho previstos no plano de gerenciamento do projeto, alm de tomar aes que evitem ou mitiguem qualquer possibilidade de desvio nos objetivos definidos. Esta funo de controle realizada durante todo o ciclo do projeto, e como resultado pode gerar solicitaes de mudana, relatrios de desempenho do trabalho e atualizaes do plano de gerenciamento do projeto e outros documentos do projeto. As solicitaes de mudana deste e de outros processos so avaliadas e aprovadas ou rejeitadas por meio de um processo especfico de realizar o controle integrado de mudanas, que ser descrito um pouco mais adiante. Durante um projeto, muitos desvios podem ocorrer, como um escopo finalizado com uma qualidade no aceitvel ou um cronograma cumprido a custos excessivos. Monitorar e controlar o trabalho do projeto uma funo de integrao, portanto seu propsito equilibrar as demandas das diferentes reas de conhecimento para controlar o projeto como um todo.
61 | CaptuLo 4
Realizando o Controle Integrado de Mudanas

Como j visto em vrios momentos durante a leitura, as mudanas fazem parte do projeto, e se bem controladas podem trazer benefcios ao resultado do projeto. A equipe pode ter planejado algo no incio, ainda com alto nvel de incerteza, que se mostra insustentvel no decorrer do projeto. Se isso ocorrer, o momento de iniciar uma solicitao de mudana. Antes desta solicitao de mudana ser autorizada, dever passar pelo crivo do processo de controle integrado de mudanas, que tem como principal atividade analisar o impacto desta mudana em todas as reas de conhecimento antes de ser aprovada. Tomando como exemplo o projeto Data Waterfall, vamos supor que no meio do projeto a equipe responsvel pela preparao da empresa para as certificaes informa que uma nova verso da norma ISO20000 acaba de ser lanada. Ao analisar criticamente a nova verso, os consultores especialistas identificam que existem novos requisitos a serem atendidos para que a empresa seja certificada. Estes requisitos no existiam antes do planejamento do projeto ser concludo. Mas se a equipe do projeto no considerar estes novos requisitos, provavelmente o datacenter no passar pela auditoria externa de certificao, e consequentemente no atender a um dos requisitos de escopo do projeto. Neste caso seria inevitvel a necessidade de documentar uma solicitao de mudana. A documentao de uma solicitao de mudana deve incluir, ao menos, o que deve ser alterado e quais so as justificativas e benefcios esperados com ela. A partir dai ser feita uma anlise do impacto desta mudana no prazo do projeto, disponibilidade de recursos, custos, riscos, etc. comum estabelecer um comit de mudanas para avaliar e autorizar mudanas em projetos. Neste comit participam especialistas e pessoas com autoridade para avaliar e aprovar ou rejeitar uma mudana. Dependendo do tamanho do projeto, ou caso no exista um comit para este tipo de aprovao, altamente recomendvel ter ao menos um fluxo interno de documentao da necessidade, avaliao do impacto, e uma definio de quem o responsvel por autorizar as mudanas (normalmente o patrocinador do projeto). Durante a avaliao de impacto, necessrio decidir entre o equilbrio das restries e como ser implantada esta mudana. Cada deciso leva a novas analises, e as ferramentas e tcnicas de gerenciamento de projetos pode ser grandes aliadas neste momento. Por exemplo, no projeto Data Waterfall h uma restrio de prazo. Para as atividades adicionais de adequao a nova verso da norma ISO20000 poderia ser utilizada algumas das tcnicas de compresso de cronograma que foram apresentadas anteriormente, como Compresso (crashing) ou Fast Track. Como a preparao para a certificao est sendo apoiada por uma consultoria externa, provavelmente ser necessrio incluir um aditivo contratual com o novo escopo. Com este exemplo, d para perceber a razo do nome controle integrado de mudanas. Finalmente, uma vez autorizada a mudana, ela deve ser refletida na EAP e na declarao de escopo do projeto, e comunicada o mais rpido possvel para a equipe e partes interessadas.
Controlando o Escopo, Cronograma, Custos e as Comunicaes

O controle de escopo, cronograma, custos e comunicaes so tratados como processos distintos pelo guia PMBOK, mas aqui sero apresentados em conjunto, pois seus propsitos so similares. Controlar o escopo significa garantir que o escopo do projeto est sendo atendido de acordo com o previsto. Controlar o cronograma significa garantir que as entregas esto sendo realizadas dentro do prazo estabelecido. Controlar os custos significa garantir que os custos do projeto no ultrapassam os limites estabelecidos. E por fim, controlar as comunicaes significa garantir que as informaes fluam da maneira planejada, na direo certa, para as pessoas certas e na hora certa. Para controlar estes elementos preciso, antes tudo, ter uma definio clara dos planos de gerenciamento e baselines, para ento medir e avaliar os dados de desempenho do trabalho com relao ao que foi definido nos planos de gerenciamento e Baselines, analisar as variaes e verificar a necessidade de mudanas.
62 | CaptuLo 4
Estes processos tm um enfoque bastante proativo. A origem das mudanas no escopo, cronograma, custo e comunicaes so analisados antecipadamente com o objetivo de evitar ou remover a necessidade de mais mudanas desta mesma origem. Voc provavelmente j deve ter ouvido falar de rally de tempo, ou rally de regularidade. Neste tipo de rally, no ganha quem chega mais rpido ao destino, mas sim quem chegou no prazo estabelecido, passou por cada ponto de controle no prazo estipulado e seguiu a trilha definida. No final, ganha quem levou menos penalizaes de tempo ou trajeto. O rally de regularidade um componente de vrios games clssicos, como Outrun, Test Drive e Need For Speed. H uma grande semelhana entre o rally de regularidade e um projeto. Em um projeto, deve ser entregue tudo que foi solicitado, e apenas o que foi solicitado, dentro do cronograma, dos custos estabelecidos e com o uso de comunicao apropriada.
Validando o Escopo
Ao contrrio do que parece, validar o escopo envolve a realizao de reunies planejadas com o cliente ou patrocinador do projeto para obter aceitao formal das entregas durante o monitoramento e controle do projeto. Para isso, o trabalho precisa estar concludo e verificado antes da reunio com o cliente. Quando o escopo no aceito (validado) pelo cliente, necessrio solicitar uma mudana, que avaliada por meio do controle integrado de mudanas, e as que so aprovadas podem levar ao replanejamento. De forma geral, espera-se que o cliente aceite as entregas. Para esta reunio com o cliente, importante ter o baseline do escopo e a documentao dos requisitos como referncia para consulta.
Controlando a Qualidade
Controlar a qualidade consiste em examinar as entregas reais produzidas no projeto. Sua finalidade garantir que as entregas estejam corretas e que cumpram o nvel de qualidade planejado, e do contrrio encontrar a causa dos problemas para recomendar maneiras de aborda-los. Se voc estiver confuso com relao similaridade entre os processos de planejamento da qualidade, realizar a garantia da qualidade e controlando a qualidade, pense da seguinte maneira: O processo de planejar a qualidade um processo de planejamento, e se preocupa em dizer o que qualidade, e como ela ser garantida durante o projeto (foco no plano de gerenciamento). O processo de realizar a garantia da qualidade um processo de execuo, e se preocupa em saber se esto sendo seguidos os procedimentos e processos conforme planejado (foco em processos). Por fim, o processo de controlar a qualidade um processo de monitorao e controle, e se preocupa em saber se os resultados do trabalho esto cumprindo os padres (foco nas entregas).
Controlando os Riscos
No se pode pensar que o assunto gerenciamento de riscos termina ao final do planejamento do projeto, quando os riscos so mapeados e onde so propostas aes de resposta para tratar os riscos. sempre possvel que novos riscos apaream durante todo o ciclo do projeto. O processo de controlar os riscos se preocupa em monitorar as ocorrncias dos riscos, implementar os planos de resposta que foram estabelecidos no planejamento, reavaliar riscos existentes e descartar riscos expirados. Esta dinmica deveria ser frequente, por meio de reunies com a equipe do projeto.
63 | CaptuLo 4
Administrando as Aquisies
O processo de administrar as aquisies diz respeito realizao de pagamentos dos contratos, recebimento e entrega de atividades reavaliadas por terceiros, aplicao de multas ou bonificaes de acordo com o que foi definido no plano de gerenciamento das aquisies. Este processo tambm se preocupa em monitorar as possveis mudanas, contratos e administrao do cronograma de pagamentos.
Controlando o Engajamento das Partes Interessadas

Manter o relacionamento com as partes interessadas e controlar o seu engajamento uma atividade continua em um projeto. Monitorar o engajamento das partes interessadas ajuda a entender as suas percepes sobre o progresso do projeto, permitindo ajustes para garantir a continuidade do engajamento e do apoio das partes interessadas. Alm de avaliar o engajamento das partes interessadas e adequar as estratgias de incentivo ao engajamento, este processo tambm envolve a reavaliao do registro das partes interessadas, incluindo novas partes interessadas, ou fazendo observaes quando o envolvimento de uma parte interessada j no se faz mais necessrio. Da mesma forma que os outros processos de controle, este processo requer que sejam identificadas as variaes do engajamento das partes interessadas com o que foi definido durante o planejamento do projeto. Quando for identificada uma variao, alm das tradicionais solicitaes de mudana pode ser utilizado tambm o registro de questes, que monitora preocupaes, discordncias e questes no resolvidas que possam surgir durante o projeto.
Encerrando o Projeto
Neste estgio final, h dois processos que se preocupam com o encerramento do projeto. Este grupo responsvel por encerrar todas as atividades e aquisies do projeto.
Encerrar aquisies
As aquisies so encerradas quando um contrato terminado ou quando um contrato rescindido antes que o trabalho seja terminado. Neste momento tambm se concluem todos os itens que por ventura no foram resolvidos, verificando se todo o trabalho e todas as entregas foram aceitos, encerrando questes pendentes e pagando as retenes de cada uma das aquisies no projeto. Em alguns casos, pode haver obrigaes contnuas, como garantias, que continuaro aps o encerramento da aquisio. Podem existir diversas aquisies em um projeto. E com isso, diversos encerramentos de aquisies. Mas todos os encerramentos de aquisies devem ser encerrados antes do encerramento final do projeto. Por este motivo, cronologicamente correto considerar que este processo predecessor ao processo de encerrar projeto ou fase do projeto.
Encerrar Projeto ou Fase

O esforo empenhado no encerramento do projeto ou fase diz respeito finalizao de todas as atividades em todos os grupos de processos, encerrando formalmente o projeto ou fase do projeto. Parece bvio, mas, o projeto no est concludo aps o fim do trabalho tcnico. O encerramento formal de um projeto se d por meio das seguintes atividades: Documentar as lies aprendidas. Durante esta leitura, voc certamente descobriu o quanto as lies aprendidas so importantes. Elas ajudam no somente a melhorar as estimativas de tempo e custo e a identificao e quantificao de riscos, como tambm servem como base de conhecimento sobre o que fazer para melhorar e o que no fazer nas prximas oportunidades (projetos). Lembre-se que as lies aprendidas so coletadas desde o planejamento do projeto, e no apenas ao final do projeto.
64 | CaptuLo 4
Transio para operao. A passagem de basto para operao uma ao que sela a participao do gerente de projetos e a equipe no projeto em questo, e define que a atuao ser exclusivamente da operao a partir da. Para proceder a passagem de basto para a operao, preciso atender a todos os critrios estabelecidos pela equipe de operao durante o projeto. muito comum encontrar cenrios de projetos que foram mal conduzidos e por isso geraram inmeros problemas na operao. Por conta disso, quem ir operar o que foi implantado pelo projeto deve participar ativamente do projeto para que seus requisitos sejam bem endereados desde o comeo. Como complemento a esta discusso, altamente recomendvel conhecer as prticas de gerenciamento de servios preconizadas pela biblioteca ITIL, principalmente os processos relacionados aos estgios de desenho e transio de servios, que complementam a compreenso (e os desafios) da passagem de basto da equipe de projetos para a equipe de operao. Aceitao formal do projeto. Seria muito desapropriado considerar um projeto ou fase do projeto encerrado sem a aprovao completa do cliente. Evento de encerramento. Ningum saber se o projeto ou fase acabou ou se parou pela metade caso no haja um evento que comunique claramente o encerramento. Faa um evento de encerramento, uma apresentao, mostre tudo que foi feito, quem participou e quais os resultados e o desempenho do projeto. Deixe claro a todos que o projeto est encerrado. Armazenamento das documentaes do projeto. Se tiver um PMO, eles armazenaro estes documentos. Liberao da equipe. Todos os recursos do seu projeto com atividades concludas esto liberados para trabalhar 100% em suas atividades dirias. Celebrao do sucesso do projeto. No deixe de comemorar o final do projeto ou fase. Lembre-se que o gerente de projetos e a equipe trabalharam muito para que tudo fosse entregue conforme estabelecido.
65 |
Sobre a COMMUNIT
A COMMUNIT uma empresa de treinamentos em TI e Gesto com mtodos de ensino que aumentam o engajamento e a absoro de contedo. Acreditamos que todas as pessoas so capazes do que quiserem fazer e tem total potencial para isso. Nosso maior objetivo provocar mudanas positivas na vida dos nossos clientes atravs da capacitao, estimulando-os a liberarem todo seu potencial. Para ns, tudo uma questo de prtica. Para saber mais sobre a COMMUNIT, acesse o site: www.communit.com.br

Fundamentos em Gerenciamento de Projetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Fundamentos em Gerenciamento de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

ANDR BERNaRDO DE OLIVEIRa REN CHIaRI

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Captulo 3 Processos de Gerenciamento de Projetos Viso Geral................................................................................ 28 Grupos de Processos................................................................ 28

Captulo 4 Aplicando as Boas Prticas de Gerenciamento de Projetos

Estudo de Caso: a Empresa SOCIALLY............................... 34

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

A histria do Gerenciamento de Projetos e o cenrio atual no mundo

Padres Globais (Standard)

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Mas afinal, o que um padro?

Standard for Program Management

Standard for Portfolio Management

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Captulos e Comunidades de Prticas

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Captulo 2 Conceitos Bsicos de Gerenciamento de Projetos

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

De onde surgem os projetos?

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

O que Gerenciamento de Projetos?

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Gerente de Projetos, o Maestro de um Projeto

Figura O Sistema Total do Projeto Fonte: STUCKENBRUCK, 1978, p.34

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Competncias em Gerenciamento de Projetos

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

O que Patrocinador (Sponsor)?

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

O que Parte Interessada (Stakeholder)?

Equipe do Projeto X Equipe de Gerenciamento do Projeto

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Escritrio de Gerenciamento de Projetos EGP (Project Management Office PMO)

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

tica e Responsabilidade Profissional

Ciclo de Vida do Projeto

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Ciclo de Vida do Produto

Processo de Gerenciamento de Projetos

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Captulo 3 Processos de Gerenciamento de Projetos

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Entradas, Tcnicas e Ferramentas, e Sadas.

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Distribuio dos Processos nos Grupos

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Gerenciamento da Integrao do Projeto

Gerenciamento do Escopo do Projeto

Gerenciamento do Tempo do Projeto

Gerenciamento dos Custos do Projeto

FUNDAMENTOS EM GERENCIAMENTO DE PROJETOS BASEADO NO PMBOK 5 EDIO

Gerenciamento da Qualidade do Projeto

Gerenciamento dos Recursos Humanos do Projeto

Gerenciamento da Comunicao do Projeto