sexta-feira, 18 de junho de 2010

PMBOK – Grupo de Processos – Iniciação


Como já dito na postagem sobre o conceito de grupos de processos, o grupo de iniciação define e autoriza o projeto ou uma fase do projeto. Normalmente, os processos deste grupo são realizados fora do escopo de controle do projeto, ou seja, as atividades desses processos são executadas por pessoas que não necessariamente fazem parte do time do projeto. Esta afirmação é bem fácil de entender quando estamos falando de um novo projeto. Neste caso ainda não existe o projeto formalizado e as pessoas que têm interesse que o mesmo seja feito devem elaborar o termo de abertura e a declaração do escopo preliminar a fim de constatar que o projeto proposto está alinhado aos interesses estratégicos da organização. Já em projetos em curso e com várias fases, os processos de iniciação são 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 não.

O grupo de iniciação é formado por dois processos (ambos da área de conhecimento da gerência de integração) a saber:

  • Desenvolver o termo de abertura do projeto.

  • Desenvolver a declaração do escopo preliminar.

Lembramos mais uma vez que a descrição detalhada dos processos será feita, por motivos didáticos, quando formos falar de cada área de conhecimento. Neste momento, o que é interessante verificar em relação aos processos que compõem o grupo de iniciação, é que os mesmos são verdadeiros tradutores das necessidades de negócio, elencadas normalmente em um planejamento estratégico. Esta tradução espelha-se no termo de abertura do projeto, que é elaborada com uma “linguagem” do negócio e pela declaração de escopo preliminar que já possui uma “linguagem” mais voltada para o gerenciamento de projetos. Dentro deste contexto, fica fácil constatar que o envolvimento dos clientes e de outras partes interessadas durante a iniciação aumenta a probabilidade de sucesso do projeto.

Na próxima postagem, falaremos do grupo de processos que detém o maior número de processos dentre todos os outros. Não deixem de acompanhar...

sexta-feira, 11 de junho de 2010

PMBOK – Coffee Break 1 – Copa do Mundo, entre outros



Nesta postagem estreamos um pequeno espaço que visa descontrair um pouco o ambiente deste blog. Sempre que acharmos que uma carga muito grande de informação foi passada sem que tivéssemos um momento de descontração, daremos uma pausa para falarmos sobre outros assuntos, já que ninguém é de ferro!!!


A Copa do Mundo está aí!!! Como sou vidrado em futebol espero acompanhar o máximo que puder (e que o trabalho deixar). Como mais um técnico, entre os milhões de brasileiros, não estou levando muita fé na nossa seleção. Nomes como Josué e Kleberson soam como estrangeiros em meio a tantos craques que o anão mestre (Dunga) deixou de fora. Apesar de todos os xingamentos e promessas de que não iremos torcer pelo Brasil, na hora que a bola rola não tem jeito, estamos lá vidrados e roendo as unhas. Sina de torcedor...

Rapidinhas:

  • Felipão no Mengão (Sonho de inverno!!!) – Como rubro-negro fiquei entusiasmado com a notícia vinculada na terça-feira dia 08/06 que dizia que o Flamengo tinha “quase tudo” acertado com o Scolari. Alegria de pobre dura pouco... duas horas mais tarde o Renato Maurício Prado (jornalista que deu a notícia) foi desmentido pela Patrícia Amorim...


  • Logo da Copa de 2014. Alguém pode me explicar que porcaria de logo é essa mostrada ao lado? Será que é o Chico Xavier psicografando? Será que é a cara de vergonha do povo brasileiro vendo as promessas de infraestrutura não serem cumpridas e o dindim público sendo desviado? Será que é um bocado de mãos dando um mega “pedala robinho”? Será que é um presságio da foto do Dunga com a nossa seleção na Copa da África? Será que é a torcida do Vasco no final do ano? Tirem suas próprias conclusões...

  • BP e o Golfo do México – Pela enésima vez a BP disse que falhou a tentativa de estancar o vazamento que tanto tem castigado o golfo do México. Não estaria na hora do mundo inteiro fazer uma manifestação? Por que a ONU não entra no assunto e alguém sério aplica uma multa daquelas?

Uuuuuuooooooooooooooonnnnnn!!! Bem, tocou o sinal, vamos voltar com a corda toda para o gerenciamento de projetos? Sigam-me os bons!!!!

quarta-feira, 9 de junho de 2010

PMBOK – Áreas de Conhecimento - Conceito

Caro leitor, na verdade não há muito o que falar sobre o conceito de áreas de conhecimento. O que podemos dizer é que as áreas de conhecimento agrupam os processos de forma lógica, dividindo-os em relação a um determinado objetivo. No total são nove áreas de conhecimento e as mesmas tratam dos tópicos que necessitam de controle e gerência para que o projeto consiga alcançar seus objetivos. Abaixo listamos todas as nove áreas de conhecimento descritas pelo PMBOK:


  • Integração do gerenciamento do projeto – Processos que fazem a “cola” entre os outros processos de cada grupo. Possuem visão integrada do projeto.

  • Gerenciamento do Escopo do projeto – Processos relacionados ao escopo do projeto.

  • Gerenciamento do Tempo do projeto – Processos relacionados ao cronograma do projeto.

  • Gerenciamento do Custo do projeto – Processos relacionados aos custos do projeto.

  • Gerenciamento dos Riscos do projeto – Processos que tratam dos riscos identificados no projeto.

  • Gerenciamento da Qualidade do projeto – Processos que fazem o controle e a garantia da qualidade do produto assim como do projeto em si.

  • Gerenciamento dos Recursos Humanos do projeto – Processos que tratam dos recursos humanos.

  • Gerenciamento das Comunicações do projeto – Processos que gerenciam a comunicação dentro do projeto.

  • Gerenciamento de Aquisições do projeto – Processo responsável por tratar com fornecedores do projeto.


Vejam que coisa linda de Deus!!! As áreas de conhecimento não estão descritas de forma aleatória. É interessante notar, conforme figura abaixo, que as áreas de conhecimento estão diretamente relacionadas com a tríplice restrição que existe em cada projeto (custo, escopo e tempo). Decorrente da gerência desses três temos a área de conhecimento responsável pela qualidade. Os processos em torno desse núcleo (riscos, comunicação e integração) garantem o andamento do projeto, protegendo o que está definido na tríplice restrição. Recursos humanos e aquisições completam o quadro alimentando a engrenagem para que tudo funcione. É ou não é algo bem pensado? Ninguém se arrepiou, nem um pouco, com esta explicação?




Nas próximas postagens voltaremos aos grupos de processos para identificarmos individualmente cada um deles. Após esta definição mergulharemos nos detalhes referentes as áreas de conhecimento, especificando melhor cada processo que o compõe.


Sigam-me os bons!!!!

sexta-feira, 4 de junho de 2010

PMBOK – Grupos de Processos - Conceito

A partir desta postagem estaremos adentrando no core business do gerenciamento de projetos, segundo o PMBOK. Este guia de melhores práticas desenvolveu uma matriz onde se encontram os processos referentes ao gerenciamento de projetos comuns à maioria dos projetos. Estes processos tratam do desempenho do projeto e têm como meta o alcance de seus objetivos. No total, a quarta edição do PMBOK possui 44 processos onde cada um pertence a uma área de conhecimento e a um grupo de processos.

Os grupos de processos, conforme já dissemos na postagem anterior, não devem ser confundidos com o ciclo de vida do projeto. Abaixo listamos os cinco grupos de processos e suas definições.

  • Grupo de Iniciação -Define e autoriza o projeto ou uma fase.
  • Grupo de Planejamento – Define e refina os objetivos e planeja as ações necessárias para alcançar os objetivos e o escopo para os quais o projeto foi criado.
  • Grupo de Execução – Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto.
  • Grupo de Controle – Mede e monitora o progresso para identificar variações em relação ao plano de gerenciamento do projeto.
  • Grupo de Encerramento – Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Durante as postagens que falarão mais especificamente de cada grupo de processos estaremos listando cada um dos processos, porém, o detalhamento dos mesmos só será feito quando formos visitar as áreas de conhecimento, por uma questão didática, certo? Neste momento, o que vale a pena tratarmos é a interação entre os processos que compõem os grupos de processos. Abaixo mostramos um gráfico que demonstra exatamente isto. Percebam algumas coisas interessantes, como por exemplo: os processos referentes ao grupo de processo de encerramento começam muito antes da finalização do projeto, assim como os processos do grupo de processo de planejamento se estendem quase até o final do mesmo.



Além desta interação 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 execução do projeto, dependendo do ciclo de vida adotado para o mesmo. A figura abaixo mostra este ciclo.



Após passarmos pelos conceitos sobre os grupos de processos, estaremos, na próxima postagem, definindo as áreas de conhecimento, antes de adentrarmos em maiores detalhes sobre cada processo... Não percam!!!

sexta-feira, 28 de maio de 2010

PMBOK – Ciclo de Vida

Nesta postagem estaremos falando de um tema que gera um pouco de confusão na cabeça das pessoas, o Ciclo de Vida de um projeto. Como teremos a possibilidade de ver nas próximas postagens, o PMBOK definiu cinco grupos de processos: o grupo de iniciação, o grupo de planejamento, o grupo de execução, 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 gerência de projeto, a definição 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 ligarão o início ao fim de um projeto e que a sua elaboração deve ser progressista. Parece ser algo bem genérico, mas é isso mesmo! Não existe um ciclo de vida ideal do projeto. O melhor caminho a seguir vai depender da organização e do produto a ser construído. 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 deverão ser executados novamente e assim sucessivamente até a entrega do produto final.


Outra confusão comum nas pessoas diz respeito a diferença entre o ciclo de vida do projeto e o ciclo de vida do produto. Não 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 experiência que passei a pouco tempo mostra exatamente isso. Fiquei como líder 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 versão final, porém no decorrer do projeto de desenvolvimento do software, certamente, este plano deverá ser revisitado e provavelmente adaptado as mudanças que certamente irão 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 satisfatória e com sucesso, graças a Deus!).





Uma última informação que julgo ser pertinente em relação ao ciclo de vida do projeto, diz respeito a influência das partes interessadas (stakeholders – ver postagem anterior) ao longo do ciclo de vida do projeto. No início do projeto, em suas fases iniciais, onde os custos da mudança são baixos, há a expectativa de que a influência dos stakeholders seja grande. Com o decorrer do tempo, é importante que esta influência esteja devidamente mitigada, pois caso venham a acontecer, o projeto poderá ter um custo maximizado, conforme demonstra gráfico abaixo.



Amigos, acredito que vamos mergulhar agora em uma fase bastante interessante do PMBOK. Vamos verificar as áreas de conhecimento e os grupos de processos.


Are you ready? So, here we go!!!!

segunda-feira, 24 de maio de 2010

PMBOK – Introdução (Parte 5) – Stakeholders

Esta pequena palavra virou moda no mundo do gerenciamento de projetos. É até chique falar stakehoders com um leve sotaque britânico (steiquerrolders, com um leve pigarro no final da palavra!). Na verdade, os stakeholders representam as partes interessadas do projeto. Alguns autores também consideram como sendo os envolvidos no projeto, apesar desta tradução não 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 organizações 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 execução ou do término do projeto. Exemplo: usuários que utilizarão o novo software, etc.
  • Podem exercer influência sobre os objetivos e resultados do projeto. Exemplo: alta direção da empresa, conselho administrativo, chefes, coordenadores, etc.

Para o PMBOK, existem as seguintes partes interessadas na grande maioria dos projetos: Clientes/usuário; membros da equipe do projeto; equipes de gerenciamento de projetos (membros da equipe que estão diretamente envolvidos nas atividades de gerenciamento); gerentes de projetos (responsável maior pelo projeto); organização executora; patrocinador (pessoa ou grupo que fornece os recursos financeiros para o projeto); influenciadores (pessoas ou grupos que não estão diretamente relacionados ao projeto, mas que, devido à posição na organização, podem influenciar o projeto) e o escritório de projetos. É importante lembrar que dependendo do projeto podem haver outros stakeholders, além dos descritos acima, porém o PMBOK considera que estes, listados acima, são os principais, presentes na maioria dos projetos. A figura abaixo representa a relação entre alguns deles e o projeto.



Com esta postagem finalizamos a introdução e os conceitos iniciais do PMBOK. Entraremos agora no meandro do PMBOK, seus processos e suas áreas de conhecimento, porém antes dedicaremos uma postagem para falarmos sobre o ciclo de vida dos projetos.

Vamos juntos...

segunda-feira, 17 de maio de 2010

PMBOK – Introdução (Parte 4) – Estruturas Organizacionais 2

Dando continuidade à introdução e aos conceitos referentes ao PMBOK, falaremos nesta postagem das estruturas matriciais encontradas nas empresas. As estruturas matriciais representam diferentes combinações das características encontradas nas estruturas funcional e projetizada.

A primeira estrutura matricial é a Matricial Fraca. Esta estrutura, conforme mostra a figura abaixo, possui características mais próximas da estrutura funcional. A função 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, não 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 efetivação de um gerente de projeto que não é o gerente funcional, ou seja, é um membro da equipe. Este gerente passa a trabalhar no projeto em tempo integral, porém 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 específico, que o conflito de dupla cadeia de comando acontece com mais evidência. Os membros da equipe acabam por ter dois “chefes”, o gerente de projeto e o gerente funcional. Dependendo da importância 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 não mais um membro de uma área funcional que interpreta este papel durante um determinado tempo. Como há, normalmente, a institucionalização de uma área onde estão 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 orçamento do projeto e na capacidade de alocar recursos. Nesta estrutura, o orçamento do projeto é controlado pelo gerente do projeto e não 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.



Na próxima postagem, deveremos terminar a parte introdutória do gerenciamento de projetos falando um pouco sobre os stakeholders ou partes interessadas. Terminada esta fase, falaremos sobre o ciclo de vida dos projetos e mergulharemos nos grupos de processos e nas áreas de conhecimento do PMBOK. Vocês não perdem por esperar!!!!