PMBook Para estrear esta nova fase do nosso blog, falaremos sobre o PMBOK, um guia que identifica um conjunto

de prticas e processos referentes ao gerenciamento de projetos amplamente reconhecidos como boas prticas pelo mercado. Um projeto pode ser definido como um esforo temporrio empreendido para criar um produto, servio ou resultado exclusivo. temporrio porque deve ter um incio e um fim bem definido. Isto vai diferenci-lo das rotinas operacionais do dia a dia, onde no h um limite de tempo, pois as tarefas acontecem ciclicamente sem um fim determinado. Deve buscar a criao de um produto, servio ou resultado exclusivo porque tem o objetivo de dar um salto de qualidade, sair de um patamar para outro mais alto. Todavia, importante deixar claro que produto, servio ou resultado exclusivo no significa, obrigatoriamente, algo indito. A presena de elementos repetitivos no muda a singularidade fundamental do trabalho do projeto. Podemos exemplificar esta ideia em relao ao lanamento de um novo modelo de carro. O desenho do novo carro sem dvida alvo de um projeto, pois, apesar de carro no ser algo indito, o trabalho de se desenhar um novo carro gerar um produto singular e exclusivo. J o processo de produo em srie deste carro, aps a sua concepo e lanamento no ser um produto de um projeto, e sim das rotinas operacionais da montadora. Como j dissemos na publicao anterior, projetos so frequentemente utilizados como meio de realizar o plano estratgico de uma organizao. Normalmente so motivados pelos seguintes fatores: Demandas de Mercado. Necessidades organizacionais. Solicitaes de clientes. Avanos tecnolgicos. Requisitos legais. Diante desses motivos, o gerenciamento de projetos, como t dando para notar, existe dentro de um contexto mais amplo que engloba tambm o gerenciamento de portflios, o gerenciamento de programas, a existncia de um escritrio de projetos (PMO - Project Managment office) e a prpria estrutura organizacional onde o projeto ser realizado. Nesta postagem estaremos falando da relao entre portflio, programas, projetos e subprojetos.

Como mostra a figura acima, entende-se como portflio, o conjunto de projetos, programas e outros trabalhos agrupados para facilitar o seu gerenciamento a fim de atender aos objetivos estratgicos de negcio. Os projetos e programas do portflio podem ser independentes entre si ou se relacionarem de forma indireta. Devemos ter em mente que o portflio definido sempre olhando para cima, ou seja, para o planejamento estratgico, j os programas, olham para baixo, para interdependncia dos projetos que os compem. J que tocamos no assunto no pargrafo anterior, programas podem ser definidos como um

grupo de projetos obrigatoriamente relacionados que so gerenciados de forma coordenada para a obteno de resultados e controles que no seriam possveis se fossem gerenciados individualmente. Nos programas podem existir elementos de trabalho fora do escopo dos projetos que os compem, assim como podem envolver uma srie de empreendimentos repetitivos ou cclicos. importante lembrar que cada projeto que compe um programa tem um ciclo de vida prprio, tem autonomia e objetivos claros e entrega um produto ou servio ao seu final. Por fim, subprojetos so divises de projetos, normalmente grandes, e no possuem vida prpria, ou seja, s fazem sentido se estiverem dentro do contexto do projeto que fazem parte. como se fossem entidades fracas em um modelo de entidade e relacionamento (pequena lembrana nostlgica da minha formao acadmica). Criar subprojeto pode ser uma estratgia bastante interessante no desmembramento de projetos que possuem vrios entregveis e vrias etapas a serem vencidas, porm no se pode esquecer que cada subprojeto dever entregar o seu produto ou servio final como se fosse um projeto, na concepo da palavra, mas este produto s far sentido se o projeto pai for tambm finalizado e entregue. O PMO (Project Management Office) ou Escritrio de Projetos, no bom e velho portugus, uma unidade organizacional que pode centralizar e coordenar o gerenciamento de projetos sob seu domnio. Na verdade verdadeira (como se dizia na minha poca de criana), no existe uma regra fixa para a montagem do Escritrio de Projetos. Cada organizao pode e deve montar esta unidade de acordo com a sua maturidade em relao gerncia de projetos e cultura organizacional. Existem alguns tipos diferentes de PMOs. Um tipo muito comum de Escritrio de Projetos aquele que tem uma funo educativa e de padronizao, onde atua como suporte ao gerenciamento de projetos por meio de treinamentos, polticas, procedimentos e padres. Um exemplo disso o PMO institudo no estado de Minnesota USA. Neste caso, conforme figura abaixo, o Escritrio de Projetos responsvel pela institucionalizao dos processos de gerncia de projetos, a fiscalizao se os mesmos so seguidos, o treinamento das pessoas envolvidas, a consultoria em relao padronizao dos processos e a definio de prticas a serem seguidas por todos os projetos.

Outro tipo de PMO aquele onde a rea atua gerenciando diretamente os projetos, com responsabilidade pelo alcance de seus resultados. Neste caso, o Escritrio de Projetos cuida tambm do gerenciamento de portflio (ver postagem anterior), onde feita uma anlise para verificar o alinhamento dos projetos que esto sob sua responsabilidade e os objetivos estratgicos da organizao. Como podemos avaliar, a forma e o poder do Escritrio de Projetos depender da estrutura da organizao em que se encontra e da forma como as pessoas esto acostumadas a trabalhar com projetos. Normalmente, o que se v nas organizaes um processo evolutivo, onde o PMO inicia-se como um institucionalizador das prticas de gerncia de projetos. Em empresas

mais maduras, em termos de gerncia de projetos, os PMOs passam a executar papis de maior responsabilidade e assumem para si o controle dos projetos estruturantes e que tero impactos mais altos nos objetivos estratgicos. Um dos grandes fatores que determinar como os projetos sero tocados o ambiente organizacional no qual os mesmos estaro inseridos. Nesta postagem falaremos sobre as estruturas organizacionais que encontramos nas empresas e suas consequncias para os projetos tocados nas mesmas. O PMBOK descreve cinco tipos diferentes de estruturas, a saber: 1 Funcional. 2 Projetizada. 3 Matricial Fraca. 4 Matricial Balanceada. 5 Matricial Forte. A estrutura Funcional, tambm chamada de estrutura Funcional Clssica, retrata as empresas onde h uma hierarquia funcional forte. Neste tipo de estrutura, cada funcionrio possui um superior bem definido e est alocado em caixinhas bem especializadas (rea contbil, rea de marketing, etc). Os projetos que so tocados nestes tipos de organizao, normalmente possuem escopos restritos aos limites da funo. Outra caracterstica interessante que o gerente de projeto , na verdade, um papel executado pelo gerente funcional, ocupando apenas parte do seu tempo para o projeto. A figura abaixo mostra este tipo de estrutura.

Na outra ponta da corda, existem as empresas que utilizam uma estrutura Projetizada. Nesta estrutura, os membros das equipes so colocados juntos. A maior parte dos recursos da organizao est envolvida no projeto e os gerentes de projetos possuem grande independncia e autoridade. As empresas que adotam este modelo possuem tambm reas com especializaes, assim como as Funcionais, mas essas reas servem de apoio para os projetos. A figura abaixo mostra como funciona a estrutura projetizada.

Dando continuidade introduo e aos conceitos referentes ao PMBOK, falaremos nesta postagem das estruturas matriciais encontradas nas empresas. As estruturas matriciais representam diferentes combinaes das caractersticas encontradas nas estruturas funcional e projetizada. A primeira estrutura matricial a Matricial Fraca. Esta estrutura, conforme mostra a figura abaixo, possui caractersticas mais prximas da estrutura funcional. A funo do gerente de projeto, realizada pelos membros da equipe, mais parecida com a de um coordenador ou facilitador do que com a de um gerente de projeto propriamente dita. Os projetos, neste tipo de estrutura, no conseguem alocar os recursos de forma exclusiva, uma vez que as pessoas fazem parte da equipe funcional ao mesmo tempo que fazem parte da equipe do projeto. Cada membro da equipe responde ao seu gerente funcional.

A estrutura Matricial Balanceada est no meio termo entre as estruturas funcional e projetizada. Nesta estrutura, h a efetivao de um gerente de projeto que no o gerente funcional, ou seja, um membro da equipe. Este gerente passa a trabalhar no projeto em tempo integral, porm a equipe do projeto continua abaixo dos gerentes funcionais, trabalhando em tempo parcial no projeto. Apesar de acontecer em todas as estruturas matriciais, nesta estrutura, em especfico, que o conflito de dupla cadeia de comando acontece com mais evidncia. Os membros da equipe acabam por ter dois chefes, o gerente de projeto e o gerente funcional. Dependendo da importncia do projeto, do chefe funcional e das regras da empresa, os membros acabam privilegiando um em detrimento do outro. A figura abaixo representa este tipo de estrutura.

Por fim, na estrutura Matricial Forte, que se assemelha mais com a estrutura projetizada, os gerentes de projetos passam a ser apenas gerentes de projetos e no mais um membro de uma rea funcional que interpreta este papel durante um determinado tempo. Como h, normalmente, a institucionalizao de uma rea onde esto os gerentes de projetos, a empresa passa a entender que os recursos devem ser alocados mais nos projetos do que nas atividades funcionais, isto significa dizer que o gerente de projeto possui maior poder. Exemplo deste poder est no oramento do projeto e na capacidade de alocar recursos. Nesta estrutura, o

oramento do projeto controlado pelo gerente do projeto e no mais pelo gerente funcional como acontece na Matricial Fraca nem por um misto entre o gerente funcional e o gerente de projeto com acontece na estrutura Matricial Balanceada. A figura abaixo mostra a estrutura Matricial Forte.

Esta pequena palavra virou moda no mundo do gerenciamento de projetos. at chique falar stakehoders com um leve sotaque britnico (steiquerrolders, com um leve pigarro no final da palavra!). Na verdade, os stakeholders representam as partes interessadas do projeto. Alguns autores tambm consideram como sendo os envolvidos no projeto, apesar desta traduo no estar 100% correta. Para melhor explicar os stakeholders, tomemos como exemplo um projeto de desenvolvimento de um software para a empresa ACME (pense em uma criatividade!!!). As partes interessadas seriam pessoas e organizaes que estariam ligadas ao projeto da seguinte forma: Ativamente envolvidas no projeto. Exemplo: desenvolvedores, arquitetos, analistas de requisitos, etc. Cujos interesses podem ser afetados como resultado da execuo ou do trmino do projeto. Exemplo: usurios que utilizaro o novo software, etc. Podem exercer influncia sobre os objetivos e resultados do projeto. Exemplo: alta direo da empresa, conselho administrativo, chefes, coordenadores, etc.

Para o PMBOK, existem as seguintes partes interessadas na grande maioria dos projetos: Clientes/usurio; membros da equipe do projeto; equipes de gerenciamento de projetos (membros da equipe que esto diretamente envolvidos nas atividades de gerenciamento); gerentes de projetos (responsvel maior pelo projeto); organizao executora; patrocinador (pessoa ou grupo que fornece os recursos financeiros para o projeto); influenciadores (pessoas ou grupos que no esto diretamente relacionados ao projeto, mas que, devido posio na organizao, podem influenciar o projeto) e o escritrio de projetos. importante lembrar que dependendo do projeto podem haver outros stakeholders, alm dos descritos acima, porm o PMBOK considera que estes, listados acima, so os principais, presentes na maioria dos projetos. A figura abaixo representa a relao entre alguns deles e o projeto.

Nesta postagem estaremos falando de um tema que gera um pouco de confuso na cabea das pessoas, o Ciclo de Vida de um projeto. Como teremos a possibilidade de ver nas prximas postagens, o PMBOK definiu cinco grupos de processos: o grupo de iniciao, o grupo de planejamento, o grupo de execuo, o grupo de controle e o grupo de encerramento. Como os nomes desses grupos nos remetem a nomes utilizados para representar fases de um ciclo de vida, comum vermos, at entre alguns autores famosos de gerncia de projeto, a definio dos grupos de processos como sendo o ciclo de vida do projeto. Isto est errado!!!! Na verdade o que o PMBOK preconiza que o ciclo de vida do projeto deve definir as fases que ligaro o incio ao fim de um projeto e que a sua elaborao deve ser progressista. Parece ser algo bem genrico, mas isso mesmo! No existe um ciclo de vida ideal do projeto. O melhor caminho a seguir vai depender da organizao e do produto a ser construdo. Assim, em um projeto de software, por exemplo, pode-se utilizar o RUP como o ciclo de vida de seu desenvolvimento e a cada marco, ou seja, a cada entrega a ser feita pelo projeto, todos, ou quase todos, os processos dos cinco grupos descritos acima devero ser executados novamente e assim sucessivamente at a entrega do produto final. Outra confuso comum nas pessoas diz respeito a diferena entre o ciclo de vida do projeto e o ciclo de vida do produto. No confundamos, por favor! Como demonstrado na figura abaixo, o ciclo de vida do produto sempre maior do que o ciclo de vida do projeto. Uma experincia que passei a pouco tempo mostra exatamente isso. Fiquei como lder de um subprojeto cujo objetivo era produzir o plano de capacidade para um grande sistema que est sendo desenvolvido(grande mesmo, com um cronograma de 5 anos). Terminado o subprojeto, o documento final, ou seja, o plano de capacidade estava pronto em sua verso final, porm no decorrer do projeto de desenvolvimento do software, certamente, este plano dever ser revisitado e provavelmente adaptado as mudanas que certamente iro acontecer no decorrer desses anos de projeto. O produto (plano de capacidade) possui, portanto um ciclo de vida muito maior que o projeto que o produziu (que finalizou de forma satisfatria e com sucesso, graas a Deus!).

Uma ltima informao que julgo ser pertinente em relao ao ciclo de vida do projeto, diz respeito a influncia das partes interessadas (stakeholders ver postagem anterior) ao longo do ciclo de vida do projeto. No incio do projeto, em suas fases iniciais, onde os custos da

mudana so baixos, h a expectativa de que a influncia dos stakeholders seja grande. Com o decorrer do tempo, importante que esta influncia esteja devidamente mitigada, pois caso venham a acontecer, o projeto poder ter um custo maximizado, conforme demonstra grfico abaixo.

PMBOK Grupos de Processos - Conceito No total, a quarta edio do PMBOK possui 44 processos onde cada um pertence a uma rea de conhecimento e a um grupo de processos. Estes processos tratam do desempenho do projeto e tm como meta o alcance de seus objetivos. Os grupos de processos, conforme j dissemos na postagem anterior, no devem ser confundidos com o ciclo de vida do projeto. Abaixo listamos os cinco grupos de processos e suas definies. Grupo de Iniciao -Define e autoriza o projeto ou uma fase. Grupo de Planejamento Define e refina os objetivos e planeja as aes necessrias para alcanar os objetivos e o escopo para os quais o projeto foi criado. Grupo de Execuo Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto. Grupo de Controle Mede e monitora o progresso para identificar variaes em relao ao plano de gerenciamento do projeto. Grupo de Encerramento Formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Alm desta interao entre os grupos de processos, importante verificar que existe um ciclo PDCA definido para o gerenciamento de projetos. Este ciclo se repete n vezes durante a execuo do projeto, dependendo do ciclo de vida adotado para o mesmo. A figura abaixo mostra este ciclo.

No total so nove reas de conhecimento e as mesmas tratam dos tpicos que necessitam de controle e gerncia para que o projeto consiga alcanar seus objetivos. Abaixo listamos todas as nove reas de conhecimento descritas pelo PMBOK: Integrao do gerenciamento do projeto. Gerenciamento do Escopo do projeto Gerenciamento do Tempo do projeto Gerenciamento do Custo do projeto Gerenciamento dos Riscos do projeto Gerenciamento da Qualidade do projeto Gerenciamento dos Recursos Humanos do projeto Gerenciamento das Comunicaes do projeto Gerenciamento de Aquisies do projeto

PMBOK Grupo de Processos Iniciao Como j dito na postagem sobre o conceito de grupos de processos, o grupo de iniciao define e autoriza o projeto ou uma fase do projeto. Normalmente, os processos deste grupo so realizados fora do escopo de controle do projeto, ou seja, as atividades desses processos so executadas por pessoas que no necessariamente fazem parte do time do projeto. Esta afirmao bem fcil de entender quando estamos falando de um novo projeto. Neste caso ainda no existe o projeto formalizado e as pessoas que tm interesse que o mesmo seja feito devem elaborar o termo de abertura e a declarao do escopo preliminar a fim de constatar que o projeto proposto est alinhado aos interesses estratgicos da organizao. J em projetos em curso e com vrias fases, os processos de iniciao so realizados entre as fases a fim de validar e verificar os resultados at aquele ponto e definir se o projeto deve continuar na fase seguinte ou no. O grupo de iniciao formado por dois processos (ambos da rea de conhecimento da gerncia de integrao) a saber: Desenvolver o termo de abertura do projeto.

Desenvolver a declarao do escopo preliminar.

Neste momento, o que interessante verificar em relao aos processos que compem o grupo de iniciao, que os mesmos so verdadeiros tradutores das necessidades de negcio, elencadas normalmente em um planejamento estratgico. Esta traduo espelha-se no termo de abertura do projeto, que elaborada com uma linguagem do negcio e pela declarao de escopo preliminar que j possui uma linguagem mais voltada para o gerenciamento de projetos. Dentro deste contexto, fica fcil constatar que o envolvimento dos clientes e de outras partes interessadas durante a iniciao aumenta a probabilidade de sucesso do projeto. PMBOK Grupo de Processos Planejamento Com 21 dos 44 processos definidos no PMBOK, o grupo de processos de planejamento o responsvel por definir e amadurecer o escopo e o custo do projeto, agendar as atividades a serem realizadas no decorrer do mesmo e desenvolver o plano de gerenciamento do projeto. No nos esqueamos que os grupos de processos no representam o ciclo de vida do projeto e por isso mesmo atualizaes decorrentes de mudanas aprovadas durante a execuo do projeto normalmente causam impacto nos planos que devem ser atualizados e revisitados durante toda a vida do projeto (elaborao progressiva). Listamos abaixo, por rea de conhecimento, cada um dos 21 processos que compe este grupo de processos. Gerncia de Integrao: Desenvolver o plano de gerenciamento de integrao. Gerncia de Escopo: Planejamento do escopo. Definio do escopo. Criar EAP. Gerncia de Tempo: Definio da atividade. Sequenciamento de atividades. Estimativa de recurso da atividade. Estimativa de durao da atividade. Desenvolvimento do cronograma. Gerncia de Custo: Estimativa de custo. Oramentao. Gerncia de Risco: Planejamento do gerenciamento de riscos. Identificao de riscos. Anlise qualitativa de riscos. Anlise quantitativa de riscos. Planejamento de respostas a riscos. Gerncia de Qualidade: Planejamento da qualidade. Gerncia de Recursos humanos: Planejamento de recursos humanos. Gerncia de Comunicao: Planejamento de comunicao. Gerncia de Aquisies: Planejar compras e aquisies.

Planejar contrataes.

Para o gerenciamento de projetos, este grupo de processos garante que os pontos chaves para que um projeto possa ter sucesso sejam verificados, planejados e analisados conforme melhores prticas. Apesar de serem muitos processos, devemos ter em mente que cada projeto poder utilizar todos ou parte desses processos, dependendo da natureza e do ambiente em que est inserido. PMBOK Grupo de Processos Execuo O grupo de processos de execuo formado por 7 processos que possuem a responsabilidade de integrar recursos e pessoas a fim de terminar o trabalho definido no plano de gerenciamento do projeto e cumprir os requisitos acordados. De fato, os processos do grupo de execuo invariavelmente envolvem a coordenao das pessoas e dos recursos alm de tratar do cumprimento do escopo definido e das mudanas aprovadas. Vejamos abaixo todos os processos que compem o grupo de processos de execuo: Gerncia de Integrao: Orientar e gerenciar a execuo do projeto. Gerncia de Qualidade: Realizar a garantia da qualidade. Gerncia de Recursos humanos: Contratar ou mobilizar a equipe do projeto. Desenvolver a equipe do projeto. Gerncia de Comunicao: Distribuio das informaes. Gerncia de Aquisies: Solicitar respostas de fornecedores. Selecionar fornecedores. Bem, em uma anlise mais superficial, uma pessoa desavisada pode dizer que o PMBOK no est l muito preocupado com a parte da execuo e sim com o planejamento, mas na verdade, no h a necessidade de se ter processos especficos em relao trplice restrio nem em relao aos riscos porque o processo da gerncia de integrao (Orientar e gerenciar a execuo do projeto) j contempla todo este trabalho, uma vez que ele segue a risca o que est definido no plano de gerenciamento do projeto, que por sua vez, engloba os planos referentes trplice restrio e aos riscos. PMBOK Grupo de Processos Monitoramento e Controle Para que os trabalhos dentro do projeto possam fluir de acordo com o que foi planejado, se faz necessrio um controle e um acompanhamento minucioso de todas as atividades do projeto. O grupo de processos de monitoramento e controle composto por 12 processos que so realizados com o intuito de observar a execuo do projeto a fim de que possveis problemas possam ser identificados no momento adequado e que possam ser tomadas aes corretivas, quando necessrio, para controlar a execuo do mesmo. Vamos listar abaixo todos os processos que compem o grupo de processos de monitoramento e controle: Gerncia de Integrao: Monitorar e controlar o trabalho do projeto. Controle integrado de mudanas. Gerncia de Escopo: Verificao do escopo. Controle do escopo.

Gerncia de Tempo: Controle do cronograma. Gerncia de Custo: Controle de custos. Gerncia de Riscos: Monitoramento e controle de riscos. Gerncia de Qualidade: Realizar o controle da qualidade. Gerncia de Recursos humanos: Gerenciar a equipe do projeto. Gerncia de Comunicao: Relatrio de desempenho. Gerenciar as partes interessadas. Gerncia de Aquisies: Administrao de contrato. PMBOK Grupo de Processos Encerramento Finalizando os grupos de processos, falaremos nesta postagem do grupo de encerramento. Este grupo de processos se preocupa com a finalizao formal de todas as atividades do projeto ou de uma fase do projeto (No se esqueam que grupo de processos no representa o ciclo de vida do projeto!!!). No caso do cancelamento do projeto, este grupo de processos tambm se responsabiliza por encerr-lo, registrando as lies aprendidas. Apenas 2 processos compem o grupo de encerramento, vejam abaixo quais so. Gerncia de Integrao: Encerrar o projeto. Gerncia de Aquisies: Encerramento do contrato. 1 - PMBOK reas de Conhecimento Gerenciamento de Integrao Daremos o pontap inicial nesta viagem com a nica rea de conhecimento que possui processos em todos os grupos de processos j vistos nas postagens anteriores: o Gerenciamento de Integrao. 1.1 Processo: Desenvolver o termo de abertura do projeto. O termo de abertura do projeto, tambm chamado de project charter, o documento que autoriza formalmente um projeto. Este documento geralmente concebido fora da organizao do projeto, por um iniciador ou por um patrocinador em um nvel adequado para financi-lo. o resultante de oportunidades, problemas ou necessidades do negcio identificadas e por isso mesmo deve possuir informaes que reflitam a viso do negcio, como por exemplo: objetivo ou justificativa do projeto, cronogramas de marcos sumarizado, justificativa financeira do projeto, oramento sumarizado, premissas e restries, influncia das partes interessadas, requisitos do produto ou do servio a ser elaborado, etc. importante lembrar que o gerente do projeto sempre deve ser designado antes do incio do planejamento e, de preferncia, enquanto o termo de abertura estiver sendo desenvolvido. 1.2 Processo: Desenvolver a declarao do escopo preliminar.

Este processo tem como base o termo de abertura, fruto do processo anterior, e aborda as caractersticas e limites do projeto alm de seus produtos e servios associados. A funo deste processo traduzir os termos de negcio existentes no termo de abertura em um nvel de projeto preliminar. Apesar de no existir uma fronteira muito clara entre a declarao do escopo preliminar e o processo de definio do escopo, que veremos mais tarde, importante distinguir que este complementa e refina as informaes contidas naquele, j que a declarao do escopo preliminar a definio do que precisa ser realizado no projeto, com uma viso preliminar e o processo de definio do escopo possui uma viso mais de projeto, preocupado em definir os entregveis do mesmo. 1.3 Processo: Desenvolver o plano de gerenciamento do projeto. Este processo tem como objetivo principal desenvolver um plano que defina como ser gerenciado o projeto, ou seja, o plano de gerenciamento de projetos dever identificar quais dos 44 processos sero utilizados, quais ferramentas, como ser a coordenao das atividades e o que ser alvo de gerenciamento. Normalmente, o desenvolvimento do plano de gerenciamento de projetos feito em dois tempos distintos: o primeiro seleciona e define a metodologia ou mtodos a serem utilizados e o segundo consolida todos os planos no plano de gerenciamento do projeto. 1.4 Processo: Orientar e gerenciar a execuo do projeto. Tambm conhecido como maestro do projeto, este processo tem como objetivo orientar o desempenho das atividades planejadas no plano de gerenciamento do projeto e gerenciar as diversas interfaces tcnicas e organizacionais que existem dentro do projeto. interessante notar que, devido existncia deste processo, no h a necessidade de existir processos de execuo para outras reas de conhecimento como escopo, tempo, custo e risco, uma vez que os planos destes processos j esto consolidados no plano de gerenciamento do projeto, alvo do gerenciamento do processo de orientar e gerenciar a execuo do projeto. 1.5 Processo: Monitorar e controlar o trabalho do projeto. Processo conhecido como capataz do projeto. Possui este apelido porque faz um comparativo entre o que foi planejado e o que foi realizado, ou seja, o processo realizado para monitorar os processos dos demais grupos (iniciao, planejamento, execuo e encerramento). o responsvel por coletar, medir e disseminar as informaes sobre o desempenho e a avaliar as medies e as tendncias para efetuar melhorias no processo. importante salientar que o capataz no o administrador, ou seja, no toma decises, apenas comunica aos outros processos o que foi coletado, medido e avaliado. 1.6 Processo: Controle integrado de mudanas. A nica certeza que temos no ciclo de vida de um projeto que teremos mudanas no decorrer de sua execuo. As mudanas podem exigir estimativas de custos, sequncia de atividades e datas do cronograma, recursos necessrios e respostas a riscos novos ou revisados. Entendese por mudana, dentro do PMBOK, as alteraes na trplice restrio (escopo, tempo e custo) e, de forma indireta, nos riscos. Isso diferente de desvio! Um desvio refere-se a um ajuste no decorrer do projeto para que o mesmo volte aos trilhos, no sendo, necessariamente, resolvido por meio de uma mudana. Cada solicitao de mudana deve ser rejeitada ou aprovada, automaticamente ou no, de forma que as mudanas aprovadas sejam incorporadas a uma linha de base revisada. Aqui surge um conceito que est sempre vinculado ao controle de mudanas nas mais diversas metodologias existentes no mercado: a existncia de um sistema de gerenciamento de configurao. Este sistema permite o controle de verses e atualizaes em qualquer item do projeto, identificando e documentando a linha de base, utilizada de forma primordial pelo processo de controle integrado de mudana, entre outros.

1.7 Processo: Encerrar o projeto. Este processo tem como objetivos principais: coordenar as atividades necessrias para verificar e documentar as entregas do projeto, coordenar e interagir para formalizar a aceitao dessas entregas pelo cliente ou patrocinador e investigar e documentar as razes para as aes tomadas se um projeto for finalizado antes do seu trmino normal. O encerramento do projeto um processo que faz o encerramento administrativo, diferentemente de outro processo, que veremos mais adiante que trata do encerramento do contrato. Este foca mais na certificao de que um produto ou servio contratado pelo projeto foi entregue de acordo com o que estava estabelecido. 2 - PMBOK reas de Conhecimento Gerenciamento de Escopo 1-Processo: Planejamento do escopo. Este processo faz parte do grupo de processos de planejamento e tem como objetivo principal descrever como a equipe ir executar os demais processos do gerenciamento de escopo. importante salientar que, apesar do plano de gerenciamento do projeto (processo do gerenciamento de integrao) definir o mtodo do projeto como um todo, a definio do mtodo do gerenciamento de escopo feita dentro do processo de planejamento do escopo. Esta definio depende da rea de atuao do projeto, por exemplo: um projeto da indstria automobilstica deve se preocupar em realizar plantas do carro, maquetes, etc., j um projeto de software dever conter casos de uso, prottipos, etc. 2- Processo: Definio do escopo. Este processo tambm faz parte do grupo de planejamento e busca detalhar o escopo do projeto a partir da declarao de escopo preliminar. Necessidades, desejos e expectativas de todas as partes interessadas, e no apenas dos patrocinadores, so analisados e convertidos em requisitos. O nvel de detalhe da declarao do escopo do projeto pode determinar a eficcia com que a equipe de gerenciamento de projetos poder controlar o escopo global do projeto. Entre os tpicos que compem a declarao de escopo detalhada, encontram-se: objetivos do projeto, descrio do escopo do produto, requisitos do projeto, limites, entregas, critrios de aceitao, restries, premissas, riscos iniciais e especificaes do projeto. 3- Processo: Criar EAP. Um dos instrumentos mais famoso na construo de um projeto a EAP. A estrutura analtica do projeto, como conhecida em portugus (WBS work breakdown structure, in english), uma decomposio hierrquica orientada entrega (produto) do trabalho a ser executado para atingir os objetivos do projeto. Esta estrutura deve ser to detalhada quanto for necessria para identificar um pacote de trabalho, ou seja, identificar uma entrega que possa ser mensurada em termos de custo e cronograma de forma que seja fcil gerenciar. importante determinar at que nvel ser detalhada a EAP pois, assim como a decomposio excessiva pode levar a um esforo grande de gerenciamento, a no decomposio pode dificultar a definio de custos e prazos.

A figura acima mostra um exemplo de EAP. Veja que o objetivo de uma EAP organizar o escopo para se definir as atividades a serem executadas, porm as atividades no fazem parte da EAP, uma vez que a mesma, como dito anteriormente, orientada a entrega. adiante. Por enquanto vamos seguir com os nossos processos da rea de gerenciamento de escopo. 4- Processo: Verificao do escopo. Processo responsvel por obter a aceitao formal das entregas pelas partes interessadas. importante salientar que este processo no trata do atendimento aos requisitos de qualidade, uma vez que isso ser realizado por outro processo. No mbito do gerenciamento de escopo, o conceito de entrega difere do conceito de produto. Enquanto aquela representa o resultado de uma ou mais atividades que compe um pacote de trabalho, este representa algo com valor para o cliente final. Os conceitos s se sobrepem quando a entrega do pacote de trabalho o produto final do projeto. 5- Processo: Controle do escopo. ltimo, porm no menos importante processo rea de gerenciamento do escopo, o controle do escopo faz parte do controle integrado de mudanas, j discutido nos processos do gerenciamento integrado. Este processo responsvel por identificar se a mudana no escopo realmente vlida e importante para o projeto. Este processo garante, tambm, que todas as solicitaes e aes corretivas recomendadas sejam processadas pelo controle integrado de mudanas. 3-PMBOK reas de Conhecimento Gerenciamento do Tempo

3.1 Processo: Definio da atividade. Este processo tem o objetivo de identificar e documentar o trabalho a ser realizado. Os pacotes de trabalho definidos quando da criao da EAP (vide postagem sobre o gerenciamento do escopo) so decompostos em componentes menores, chamados de atividades do cronograma. importante lembrar que uma atividade diferente de um pacote de trabalho. Enquanto este representa a menor unidade de entregveis de uma EAP, as atividades mostram o que deve ser feito para que o pacote de trabalho possa ser entregue. 3.2 Processo: Sequenciamento de atividades. As atividades, aps terem sido definidas, devem ser sequenciadas usando as relaes de precedncia adequadas. Este processo busca, exatamente, colocar as atividades nas suas relaes de precedncia de forma a suportar o desenvolvimento de um cronograma do projeto realista e alcanvel. A precedncia pode ser normal, de antecipao ou de atraso e possui os

seguintes tipos: trmino para incio (TI a iniciao da atividade sucessora depende do trmino da atividade predecessora), trmino para trmino (TT o trmino da atividade sucessora depende do trmino da atividade predecessora), incio para incio (II a iniciao da atividade sucessora depende da iniciao da atividade predecessora) e incio para trmino (IT o trmino da atividade sucessora depende da iniciao da atividade predecessora). As dependncias entre as atividades tambm podem ser classificadas como: obrigatrias (dependncias inerentes natureza do trabalho realizado lgica rgida), arbitradas (estabelecidas com base no conhecimento das melhores prticas dentro da rea de aplicao do projeto lgica preferida ou fina) e externas (envolvem relacionamentos com atividades que no so da governana do projeto). O sequenciamento de atividades podem ser representados por diagramas chamados como diagramas de rede. Os mais famosos so o MDP (mtodo do diagrama de precedncia) e o MDS (mtodo do diagrama de setas). Essas representaes no mostram o tipo de relao de precedncia e nem a distribuio relativa das atividades no tempo, mas so muito teis na definio do caminho crtico do projeto. 3.3 Processo: Estimativa de recursos da atividade. Este processo responsvel por determinar os recursos a serem consumidos nas atividades. Quando se fala de recursos, estamos tratando de pessoas, equipamentos e materiais, ou seja, tudo o que for necessrio para a execuo da atividade. importante lembrar que este processo tem uma relao muito estreita com o processo de estimativa de custos da rea de conhecimento chamada de gerenciamento de custos, que ainda veremos mais para frente. 3.4 Processo: Estimativa de durao da atividade. Este processo determina o esforo necessrio para terminar cada atividade do cronograma. Naturalmente, a estimativa de durao das atividades elaborada de forma progressiva, com base na qualidade e disponibilidade dos dados. Existem trs diferentes tipos de estimativas, a saber: a estimativa anloga, a estimativa paramtrica e a estimativa de trs pontos. A estimativa anloga aquela estimativa baseada na experincia da pessoa que faz a estimativa. uma percepo pessoal, normalmente baseada na durao real de uma atividade anterior com caractersticas semelhantes. mais usada quando a quantidade de informaes limitada, como por exemplo, no incio do projeto. A estimativa paramtrica tem como base um histrico, no ficando presa a experincia pessoal. Um exemplo ntido o uso da anlise de pontos de funo para determinar a produtividade a ser medida em homem-hora. Esta mtrica permite estimar atividades correlatas, sempre se baseando no histrico existente na empresa. A estimativa de trs pontos usa uma mdia de trs duraes estimadas. Estas duraes baseiam-se em uma estimativa otimista, uma pessimista e uma mais provvel. A partir desta definio pode-se utilizar uma mdia ponderada, como no caso da estimativa utilizada por PERT, atribuindo os seguintes pesos: 1- otimista, 4 mais provvel e 1 pessimista. 3.5 Processo: Desenvolvimento do cronograma. Processo iterativo que determina as datas de incio e trmino planejadas das atividades. Possui elaborao progressiva e continua durante todo o projeto. Um dos pontos altos deste processo est na anlise de rede de cronograma. Rede de cronograma uma tcnica que emprega mtodos analticos que tem como objetivo calcular as datas de incio e trmino mais cedo e mais tarde, alm das datas de incio e trmino agendadas para as atividades do projeto. Os mtodos mais utilizados na criao da rede de cronograma so: mtodo do caminho crtico (CPM), nivelamento de recursos e anlise PERT. No tenho a inteno de explanar tudo sobre esses mtodos, pois teramos que criar um novo

blog s para isso, mas na figura abaixo apresento um diagrama de rede com CPM. O objetivo do CPM determinar as folgas nos diversos caminhos da rede de atividades do projeto. A partir desta anlise determina-se a durao mnima total do projeto. Veja que as atividades ligadas pela linha vermelha representam o caminho crtico, ou seja, se atrasarem a data final do projeto certamente estar comprometida.

Aps a anlise do caminho crtico utiliza-se a tcnica do nivelamento de recursos para abordar situaes de choque de recursos compartilhados. Este trabalho pode fazer com que o caminho crtico original mude. Finalmente, a tcnica de PERT permite, por meio de probabilidade, determinar a chance de um determinado cronograma terminar dentro do prazo estipulado. 3.6 Processo: Controle do cronograma. Por ltimo, porm no menos importante, o processo de controle do cronograma faz parte do controle integrado de mudanas, j discutido nos processos do gerenciamento integrado. Este processo responsvel por determinar o andamento atual do cronograma do projeto, controlar os fatores que criam mudanas no cronograma e gerenciar as mudanas conforme elas efetivamente ocorram. 4 - PMBOK reas de Conhecimento Gerenciamento de Custos Esta rea possui os processos necessrios para que o projeto termine dentro do oramento aprovado. interessante notar que, para o PMBOK, o gerenciamento de custos trata principalmente dos custos dos recursos necessrios para terminar as atividades, ou seja, dos custos referentes aos recursos alocados nas mesmas. Desta forma, se um empregado estiver de greve, por exemplo, o seu salrio no conta como custo do projeto durante o perodo de greve, uma vez que neste perodo o empregado em questo no estava realmente alocado em uma determinada atividade do projeto. 4.1 Processo: Estimativa de custos. Processo responsvel pelo desenvolvimento de uma estimativa inicial, como o prprio nome do processo sugere, dos custos referentes aos recursos necessrios para terminar cada atividade do cronograma. importante lembrar que nesta estimativa deve ser levado em considerao as possveis causas de variaes nos custos, inclusive os riscos inerentes atividade sendo estimada. Assim como no gerenciamento do tempo, a estimativa de custos deve ser refinada com o caminhar do projeto. Tambm como na estimativa do prazo das atividades, a estimativa dos custos pode ser anloga ou paramtrica. 4.2 Processo: Oramentao. Como o prprio nome do processo j diz, o responsvel pela elaborao do oramento do projeto. As estimativas de custos so preparadas antes das solicitaes de oramento detalhado e da autorizao do trabalho. Este processo representa a agregao dos custos estimados de atividades ou pacotes de trabalho para estabelecer uma linha de base dos custos para a medio do desempenho do projeto.

4.3 Processo: Controle de custos. O processo de controle do custo faz parte do controle integrado de mudanas, j discutido nos processos do gerenciamento integrado. O controle de custos do projeto inclui, entre outros objetivos, o controle dos fatores que criam mudanas nos custos, a monitorao das mudanas reais quando e conforme ocorram e o monitoramento do desempenho dos custos para detectar e compreender as variaes em relao linha de base. Este ltimo objetivo realizado por meio da anlise do valor agregado. A anlise do valor agregado uma tcnica que utiliza a linha de base dos custos para avaliar o andamento do projeto e a extenso das variaes de escopo, tempo e custo. Tem como base as seguintes medidas: Valor Agregado (VA) Custo orado para o trabalho realmente terminado at o momento da anlise. Avalia o escopo, ou seja, o quanto o projeto acha que o valor das atividades realizadas valem. Valor Planejado (VP) Custo orado do trabalho agendado a ser terminado no moment o que est sendo realizado a anlise. Avalia o tempo, o que foi agendado para ser executado at um determinado momento. Custo Real (CR) Custo total incorrido na realizao do trabalho at o momento da anlise. A partir das medidas descritas acima, pode-se analisar o andamento do projeto. Esta anlise feita por meio das seguintes medidas derivadas: Variao de Custos (VC = VA CR) Variao de Prazos (V. Prazos = VA VP) ndice de Desempenho de Custos (IDC = VA/CR) ndice de Desempenho dos Prazos (IDP = VA/VP) Progresso Geral do Projeto (Prog. Geral = VA/Oramento total) 5- PMBOK reas de Conhecimento Gerenciamento da Qualidade O gerenciamento da qualidade formado pelos processos envolvidos na garantia de que o projeto ir satisfazer os objetivos para os quais foi realizado. importante salientar que a qualidade no vista apenas sob a tica do produto ou servio produzido pelo projeto. Ela tambm aborda a qualidade dos processos que fizeram com que o projeto chegasse a um final. 5.1 Processo: Planejamento da qualidade. Este primeiro processo do gerenciamento da qualidade responsvel por identificar os padres de qualidade relevantes para o projeto e determinar como satisfaz-los. Esta identificao pode ser feita por meio de uma ferramenta bastante famosa no meio dos projetos, o Benchmarking. Esta ferramenta permite comparar a sua organizao com outras organizaes e assim determinar quais sero os padres de qualidade que devero ser definidos e atendidos. No deixe de perceber uma grande mxima: qualidade planejada, projetada e incorporada e no apenas inspecionada. O que isso quer dizer? Qualidade no feita apenas no final da cadeia produtiva, quando o produto ou servio entregue, algo que deve ser cuidada em toda as fases do ciclo de vida do projeto. 5.2 Processo: Realizar a garantia da qualidade. Este processo busca a aplicao de atividades planejadas e sistemticas para garantir que o projeto ir empregar todos os processos necessrios para atender aos requisitos acordados. Como se pode observar, o foco aqui nos processos, ou seja, no estamos verificando se o produto/servio final est de acordo com os requisitos, na verdade o que se quer, neste processo garantir que tudo ser feito para que o produto ou servio seja feito de acordo com o que foi requisitado.

5.3 Processo: Realizar o controle da qualidade. Feito normalmente por amostragem, este processo tem o foco no produto ou servio realizado pelo projeto. responsvel por monitorar os resultados especficos para determinar se esto de acordo com os padres de qualidade. A equipe de controle de qualidade deve ter um conhecimento prtico de controle estatstico da qualidade, especialmente de amostragem e probabilidade, para ajudar a avaliar as sadas do processo. Uma ferramenta muito utilizada a tcnica de Paretto ou, como tambm conhecida, regra 80/20. 6- PMBOK reas de Conhecimento Gerenciamento de Riscos Sendo uma rea de conhecimento muito importante, o gerenciamento de riscos visa, basicamente, aumentar a probabilidade e o impacto de eventos positivos e diminuir a probabilidade e o impacto de eventos adversosPara o PMBOK, assim como para outras metodologias/prticas, o risco pode ser positivo. A definio correta, na viso do PMBOK, a seguinte: o risco um evento ou condio incerta que, se ocorrer, ter um efeito positivo ou negativo sobre pelo menos um objetivo do projeto. Desta forma os processos desta rea de conhecimento tratam de todos os aspectos relevantes em relao aos riscos que podem vir a acontecer em um projeto, seja ele positivo ou negativo. 6.1 Processo: Planejamento do gerenciamento de riscos. O plano de gerenciamento de riscos define, entre outros itens, a metodologia a ser usada, as funes/responsabilidades, a oramentao, as categorias de risco, a definio da escala de probabilidade e impacto dos riscos, a matriz de probabilidade e impacto, os formatos de relatrios, etc. As figuras abaixo mostram exemplos de categorizao de risco (identificadas em uma EAR Estrutura analtica de riscos), escalas de impacto de um risco e a matriz de probabilidade e impacto respectivamente.

EAR - Estrutura Analtica de Riscos

Escala de Impacto

6.2 Processo: Identificao de riscos. Este processo responsvel por determinar os riscos que podem afetar o projeto e documentar as suas caractersticas. O processo de identificao de riscos deve ser feito de forma iterativa e pode se valer de vrias formas de informao, como por exemplo: informaes histricas, tcnica de brainstorming, mtodo de delphi, entrevistas, etc. A identificao de riscos leva naturalmente anlise qualitativa dos mesmos, apesar de que, alternativamente, pode levar diretamente anlise quantitativa, mas isso s seria aconselhvel caso o universo dos riscos fosse bastante limitado. 6.3 Processo: Anlise qualitativa de riscos. Este processo permite priorizar quais riscos devem ser tratados inicialmente. um mtodo subjetivo de priorizao de riscos identificados que avalia a prioridade com base na probabilidade de ocorrerem e seu impacto nos objetivos do projeto. 6.4 Processo: Anlise quantitativa de riscos. Este processo, por ser mais complicado de executar, deve ser feito com os riscos que foram priorizados pela anlise qualitativa de riscos. Utiliza-se de tcnicas como simulao de Monte Carlo e anlise da rvore de deciso para avaliar a probabilidade de atingir objetivos especficos e identificar os riscos que exigem mais ateno e sua contribuio relativa para o risco total do projeto. A simulao de Monte Carlo feita por meio de softwares especializados e deve ser utilizado quando se tem um nmero maior de riscos e o efeito deles cumulativo. J a rvore de deciso deve ser utilizada quando se tem poucos riscos e se deseja tomar uma deciso especfica. 6.5 Processo: Planejamento de respostas a risco. Aps identificar e fazer a anlise qualitativa e quantitativa dos riscos de extrema importncia que a organizao planeje as respostas que dever ter para estes riscos. O processo de planejamento de respostas a risco tem a finalidade de desenvolver opes e determinar aes para aumentar as oportunidades e reduzir as ameaas aos objetivos do projeto. Essas aes podem ser antes do risco acontecer ou depois do risco ter se concretizado. Existem trs estratgias de respostas aos riscos que tem impactos negativos e trs estratgias de respostas aos riscos que possuem impacto potencialmente positivos. Abaixo descrevemos cada uma delas. Impactos Negativos

Prevenir a estratgia que busca reduzir a probabilidade ou o impacto do risco a zero. Transferir a estratgia que faz a passagem do impacto negativo de uma ameaa para terceiros, assim como num seguro. Mitigar a estratgia que busca reduzir a probabilidade e/ou o impacto at um limite aceitvel.

Impactos Positivos Explorar a estratgia que busca garantir que a oportunidade seja concretizada. Compartilhar a estratgia que faz a atribuio da propriedade para terceiros para que possam capturar melhor a oportunidade em benefcio do projeto. Melhorar a estratgia que busca aumentar a probabilidade e/ou o impacto dos riscos positivos. 6.6 Processo: Monitoramento e controle dos riscos. Este processo responsvel por monitorar e controlar os riscos por meio da identificao, anlise e planejamento dos riscos novos que por ventura venham a aparecer no decorrer do andamento do projeto e do acompanhamento e reanlise dos riscos j identificados. Este processo tambm faz uma reviso da execuo das respostas aos riscos que tenham sido planejadas. 7 PMBOK reas de Conhecimento Gerenciamento de Recursos Humanos A rea de gerenciamento de recursos humanos trata dos processos que organizam e gerenciam a equipe do projeto. H quem diga que gerenciar projetos na verdade, coordenar e gerenciar pessoas para atingirem um determinado objetivo comum. 7.1 Processo: Planejamento dos recursos humanos. Este processo responsvel por determinar os papis, responsabilidades e relaes hierrquicas do projeto, alm de criar o plano de gerenciamento de pessoal. A atribuio de responsabilidades pode ser feita para pessoas ou grupos que por sua vez podem ser internos ou externos organizao que executa o projeto. 7.2 Processo: Contratar ou mobilizar a equipe do projeto. O objetivo principal do processo de contratar ou mobilizar a equipe do projeto obter os recursos humanos necessrios para terminar o projeto, ou seja, as pessoas necessrias para fazer o que foi estimado. 7.3 Processo: Desenvolver a equipe do projeto. Este processo visa melhorar as competncias e a interao dos membros da equipe para aprimorar o desempenho do projeto por meio de treinamentos, capacitaes e trabalhos que busquem o aumento da sinergia da equipe, ou seja, trabalhos que busquem aprimorar os sentimentos de confiana e coeso. 7.4 Processo: Gerenciar a equipe do projeto. Este ltimo processo do gerenciamento de recursos humanos tem o objetivo de acompanhar o desempenho dos membros da equipe do projeto, fornecendo feedbacks, resolvendo problemas e gerenciando possveis mudanas com intuito de melhorar o desempenho. 8- PMBOK reas de Conhecimento Gerenciamento das Comunicaes O gerenciamento das comunicaes composto por processos que se preocupam em gerar, coletar, disseminar, armazenar e fazer com que as informaes tenham a destinao correta, de forma oportuna e adequada. A seguir detalharemos cada um desses processos.

8.1 Processo: Planejamento das comunicaes. Este processo responsvel por determinar as necessidades de informaes e comunicaes das partes interessadas. responsvel, tambm, pela identificao do mtodo como se dar a comunicao dentro do projeto e pela elaborao do plano de gerenciamento das comunicaes. Este plano fornece algumas informaes importantes, como por exemplo: os requisitos de comunicao das partes interessadas; as informaes que sero comunicadas, inclusive o formato, o contedo e o nvel de detalhe; a pessoa responsvel pela comunicao; as pessoas ou grupo de pessoas que iro receber as informaes, a frequncia da comunicao e os mtodos ou tecnologias usadas para transmitir as informaes (e-mail, memorando, cartas internas, etc). 8.2 Processo: Distribuio das informaes. Este processo busca colocar as informaes disposio das partes interessadas no momento oportuno e de acordo com o que foi definido no plano de gerenciamento das comunicaes. importante salientar que este processo no est preocupado em processar as informaes e gerar relatrios consolidados, ele apenas faz com que as informaes, uma a uma, cheguem a quem de direito. Poderamos resumir este processo na seguinte frase: o processo responsvel por fazer a informao circular pelo projeto durante a sua execuo. No podemos deixar de mencionar a possibilidade de surgirem solicitaes de informaes no previstas. Nestes casos , este processo tambm ser o responsvel por resolver o problema. 8.3 Processo: Relatrio de desempenho. Diferentemente do processo anterior, este processo faz a coleta dos dados de linha de base e distribui as informaes de forma consolidada sobre o desempenho do projeto para as partes interessadas. O relatrio de desempenho normalmente reflete uma comparao entre o que foi planejado e o que est sendo executado at o momento. comum tambm vermos, neste relatrio, as anlises de valor agregado, que falamos nas postagens referentes aos processos de gerenciamento de custos. 8.4 Processo: Gerenciar as partes interessadas. Este processo trata, basicamente, do gerenciamento ativo das partes interessadas. Gerenciamento ativo significa satisfazer as necessidades das partes interessadas no projeto e resolver problemas com elas. Este processo importante porque pode reduzir de forma significativa a probabilidade do projeto se desviar do curso por causa de problemas no resolvidos das partes interessadas, alm de aumentar a capacidade das pessoas trabalharem em sinergia. 9- PMBOK reas de Conhecimento Gerenciamento das Aquisies Esta rea de conhecimento a responsvel por gerenciar os outros recursos que no sejam pessoas ou informaes. O gerenciamento das aquisies composto pelos processos que compram ou adquirem produtos, servios e/ou resultados e pelos processos que fazem o gerenciamento dos contratos firmados. A seguir exploraremos cada um desses processos. 9.1 Processo: Planejar compras e aquisies. Este processo busca identificar quais, dentre as necessidades do projeto, podem ser melhor atendidas pela compra ou aquisio de produtos, servios ou resultados. Perguntinha de vestibular... Quem viria primeiro, compras ou contrataes? Na verdade existe uma ordem cronolgica entre as compras e contrataes, segundo o PMBOK. O primeiro trata das questes estratgicas e o segundo diz respeito as questes operacionais. Por isso, antes das contrataes, o projeto deve se preocupar com o que comprar. Os demais processos do gerenciamento das aquisies sero executados para cada item a ser

comprado ou adquirido. 9.2 Processo: Planejar contrataes. Este processo tem uma viso mais operacional. Ele responsvel por preparar a documentao necessria para dar suporte a outros dois processos: solicitar repostas de fornecedores e selecionar fornecedores. importante lembrar que a complexidade e o nvel de detalhes dos documentados devem estar de acordo com o valor da compra planejada, os riscos associados a ela e as questes legais referentes compra ou aquisio de produtos e servios. 9.3 Processo: Solicitar respostas de fornecedores. o processo responsvel por obter respostas, como cotaes e propostas, de possveis fornecedores sobre como os requisitos do projeto podem ser alcanados. Trocando em midos e colocando dentro da realidade brasileira, este processo seria o responsvel por publicar o edital de compra e receber as propostas. 9.4 Processo: Selecionar fornecedores. Este processo recebe cotaes ou propostas e conforme critrio anteriormente definido (menor preo, melhor tcnica, tcnica e preo, etc) seleciona um ou mais fornecedores que sejam qualificados. Colocando no nosso mundo tupiniquim seria o processo responsvel pela adjudicao e contratao do fornecedor. 9.5 Processo: Administrao de contrato. Este processo garante que o desempenho do fornecedor atende aos requisitos contratuais. Alm disso controla o comprador para que o mesmo atue de acordo com os termos do contrato. Um fator importante para o projeto garantir que a natureza legal da relao contratual seja respeitada e que a equipe de gerenciamento do projeto esteja a par das implicaes legais das aes tomadas durante a administrao de qualquer contrato. 9.6 Processo: Encerramento do contrato. Este processo d suporte a outro processo visto no gerenciamento de integrao, o processo de encerramento do projeto. Ele responsvel por confirmar que o trabalho ou produto contratado foi entregue conforme acordado alm de registrar e arquivar as informaes pertinentes ao contrato. A resciso de um contrato um caso especial de encerramento do contrato e pode resultar de um acordo mtuo entre as parte ou descumprimento das obrigaes de uma das partes.

PMBOK Diferenas entre a 4a e a 3a edio Ciclo de vida do projeto Segundo o PMBOK na sua 4a edio, todos os projetos podem ser mapeados para uma estrutura genrica de ciclo de vida. Conforme figura abaixo, esta estrutura est dividida em: incio do projeto, organizao e preparao, execuo do trabalho do projeto e encerramento do projeto.

Essas fases do ciclo de vida do projeto podem ter as seguintes relaes: Sequenciais, sobrepostas e iterativas. De forma geral, em fases sequenciais h a diminuio das incertezas, mas pode eliminar a possibilidade de reduo do cronograma. Em fases sobrepostas pode existir o retrabalho, se uma fase subsequente progrida antes que as informaes corretas sejam disponibilizadas pela fase anterior. Finalmente, em fases iterativas, apenas uma fase est planejada a qualquer momento e o planejamento da prxima fase feito medida que o trabalho avana. Neste tipo de ciclo de vida, o escopo gerenciado por entregas contnuas de incrementos do produto e priorizao de requisitos para minimizar riscos e aumentar o valor comercial do projeto. reas de conhecimento Em relao s reas de conhecimento, o PMBOK padronizou os nomes dos processos, alterando os nomes de todos aqueles que no comeavam com um verbo no infinitivo. Agora, todos os processos seguem esta nova regra, como por exemplo, o processo Controle integrado de mudanas que passa a se chamar Realizar o controle integrado de mudanas. Alguns processos foram extintos, outros criados e ainda outros mudaram de grupo de processos. A seguir colocamos quadros com as alteraes ocorridas em cada um das reas de conhecimento.

Gerncia de Integrao

Gerncia de Escopo

Processo:Coletar os requisitos Este novo processo tem o objetivo de definir e documentar as funcionalidades do projeto e do produto. Esses requisitos serviro de base para a criao da EAP e pode ser dividida em

requisitos do projeto e requisitos do produto. importante deixar claro que os requisitos devem ser coletados com detalhes suficientes que permitam que os mesmos sejam medidos durante a execuo do projeto. Gerncia de Tempo

Gerncia de Custos

Gerncia de Riscos

Gerncia da Qualidade

Gerncia de Recursos Humanos

Gerncia das Comunicaes

Gerncia das Aquisies