Projetizando a Vida

Oi Pessoal,

A Partir  do dia 10/05/2010 estarei ministrando 0 curso de  Gerenciamento de Projetos com as práticas do PMBOK 2008 na Stefanini Training, que fica em São Paulo na Avenida Angélica.

É um curso para Gerentes de Projeto Iniciantes que queiram conhecer(Ou conhecer mais sobre) o PMBOK.

O Curso tem 32 horas e será ministrado as Segundas/Quartas e Sextas. O Investimento para esse custo está com valor bastente  interessante é de apenas  R$  702,00.

Mais Informações e Inscrições através do Site da Stefanini Training

Já ouvi muita gente colocar o Agile Software Development como uma metodologia alternativa ao PMBOK, quando vejo isso fico em dúvida se dou risada ou se choro…

Primeiro porque não existe “Agile Management”,  Agile Software Development é na verdade um conjunto de metodologias de desenvolvimento, e dentro de cada uma delas, se quisermos ter sucesso precisaremos gerenciá-las da melhor forma possível.

Em segundo lugar porque o PMBOK não é, nunca foi e nunca vai ser uma metodologia, ele é um guia das melhores práticas de Gerenciamento de Projetos.

Ele é um livro que se for usado com bom senso será ume excelente base para a criação de uma metodologia de gerenciamento que poderá sim ser ágil e adequada ao Agile Software Development.

Querem um Exemplo Prático ?

Uma das metodologias ágeis que eu mais gosto é o SCRUM.

Por curiosidade, SCRUM é aquela formação que os jogadores de Rugbi fazem onde os dois times se apóiam ombro a ombro para lançarem a bola, não sei porque e nem quando, mas a estrutura é aquela e chama-se SCRUM…

Explicando de forma hiper-super-extremamente resumida, na metodologia SCRUM, o projeto é dividido em pequenos entregáveis, de forma que o sempre tenha algum módulo entregue e aprovado na pior das hipóteses a cada quinzena, o ideal é que essa entrega seja semanal.

Diariamente a equipe se reúne, numa reunião em pé,  na frente de um quadro negro (atualmente quadro branco, com pinceis ao invés de giz), com duração de 15 minutos para responder a apenas 3 perguntas:

* O que fiz desde ontem?

* O que estou planejando fazer até amanhã?

* Existe algo me impedindo de atingir minha meta?

Terminada essa reunião cada um já sabe o que tem que fazer, e todos vão ao trabalho.

Alem disso existem algumas características adicionais nos projetos de SCRUM:

* Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);

* Entregas freqüentes e intermediárias de causam reuniões freqüentes com os stakeholders (todos os envolvidos no processo) ;

* Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;

* Transparência no planejamento e desenvolvimento;

* Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;

Por isso deixo uma pergunta: Onde é que o SCRUM (assim como outras metodologias Ageis) está confrontando com o PMBOK?

Na minha opinião usar uma abordagem de Agile Software Development sem o Apoio do PMBOK é partir para um “Desenvolvimento Cowboy”,  ou seja,s e o bandido mexer, você  saca e atira, e torce pra ele não sacar mais rápido…

Mas voltarei a falar mais sobre SCRUM e vou convidar um amigo Nelson Abu Samra Rahal Junior, o Abu, especialista em SCRUM  e autor do Blog do Abu para fazer parte da  Equipe do Projetizando a vida, escrevendo com mais propriedade sobre o assunto.

Todo mundo que já gerenciou ou mesmo já participou de alguns projetos deve ter ouvido, ou até mesmo dito essa frase,d e maneira mais ou menos educada…

Existe uma estatística do PMI que diz que 80% dos projetos não terminam no prazo, com o custo estimado ou com as características prometidas, isso quando não acontece as 3 coisas, ou seja, em maior ou menos escala 80% dos projetos dão M….

Quando falo isso não estou falando de projetos públicos, que muitas vezes nascem já se sabendo que vai estourar a verba, nem de projetos gigantescos com inúmeras variáveis, falo de projetos no sentido mais amplo…

O PMBOK, as metodologia de gerenciamento e até este blog se propõe a auxiliar para que esse percentual de falhas.

Muita gente usa a palavra fracasso, eu não gosto de usá-la, pois fracasso é algo definitivo, já falha é algo corriqueiro e contornável, QUASE sempre é possível recolocar o projeto nos trilhos, e isso depende, fundamentalmente, do Gerente de Projetos.

Mas o que um Gerente de Projetos PODE e PRECISA fazer, quando um Projeto dá M…. ?

O Que PODE ser feito Depende de alguns fatores, como Bom Sendo, Domínio da situação, Autonomia e Coragem.

A Autonomia de um GP depende do tipo de organização em que ele trabalha, mesmo num projeto pessoal, como seu Projeto de Vida, existe uma organização envolvida, a Organização Familiar, um GP solteiro que não tem ninguém que dependa dele tem autonomia maior, ou quase total , já quando se tem dependentes, sejam esposa(o), filhos, pais ou agregados, a autonomia não é tão grande.

Domínio da situação também é fundamental, e nem sempre depende do GP, entra ai o Bom Sendo, para definir tudo isso.

E finalmente a Coragem, muitas vezes você precisa dar a cara pra bater, assumir o erro e isso nunca é fácil.

Agora, o que o Gerente de Projetos PRECISA fazer?

A Primeira atitude do Gerente de Projetos é identificar o problema, quanto antes o Problema for detectado, menos o custo para corrigi-lo.

A Primeira coisa é admitir para SI MESMO que alguma coisa está errada, e esse é um dos passos mais difíceis.

Identificado o problema é preciso avaliar o impacto no resultado final do projeto.

Avaliado o Impacto é preciso determinar os caminhos a seguir, normalmente existe mais do que um, se você só vê um caminho CUIDADO, se não existe decisão a ser tomada, provavelmente não é necessário um Gerente de Projetos…

Uma possibilidade que muita gente ignora é a de deixar rolar.

Determinadas as soluções possíveis, é preciso uma análise de Custo X Benefício: Qual é o custo (em termos de esforço, prazo, imagem, credibilidade, etc.) de cada uma delas, inclusive de deixar rolar.

Com essa análise feita entra a CORAGEM, ou seja escolher a melhor opção PARA O PROJETO, e na para o Gerente.

Resta agora replanejar tudo, e aqui é preciso cuidado. Um replanejamento em um projeto é normal, dois é aceitável, três é crítico…

Mas existe projetos com MUITOS replanejamentos, isso demonstra falta de planejamento, falta de Experiência, de bom Sendo ou de Coragem.

Existem projetos que não simplesmente não são possíveis de serem executados, é verdade, mas isso só demonstra falta de Bom Senso, deveria ser quebrado em atividades menores e cada uma ser tratada como um projeto a parte.

Quando falo em Coragem é a coragem de assumir que a nova data final é inatingível, o que via causar novo replanejamento, o que deve ser feito é pensar numa data REALISTA e defendê-la “até a morte”.

Um “detalhe” importante é determinar com muito cuidado as causas do problema, para evitar que os erros se repitam.

Mas vamos a um exemplo prático, uma M…. real!

Como falei no artigo sobre planejamento, 90% dos problemas de projeto se devem a erros de planejamento, e o erro mais comum é desprezarmos “fatores externos”…

Quando comecei meu projeto de escrever uma série de artigos sobre Grupo de Processos no PMBOK me comprometi com um cronograma de 2 artigos por semana, ignorando fatores externos como meu emprego que me consome 10 H/dia, meus outros blogs (Blog Profissional e Boteco Futebol), alguns clientes blogueiros e minha família…

Resultado: Cronograma comprometido. Precisei fazer na semana passada um primeiro Re-Planejamento, e sem avaliar corretamente o problema, me comprometi a “retirar o atraso”…

Na maioria dos projetos quando assumimos essa retirada de atraso, aproveita-se algo que já tem, com pequenas adaptações e deixa-se de fazer atividades “desnecessárias”, como testes e controle de qualidade (Alguem já viu isso acontecer?).

Resultado uma grande M…..!

Nesse caso aproveitei alguns artigos antigos e “cumpri o cronograma”, só que meu “controle de qualidade” deixou passar um detalhe, o artigo era baseado no PMBOK 2000 e não no PMBOK 2004 !!!!!

Resultado, novo replanejamento, dessa vez com maior cuidado, correção do problema (O Grupo planejamento foi re-escrito e o de Execução foi “retirado para revisão”).

Depois disso estabeleci um novo cronograma, agora levando em conta atividades “extra-projeto” e publicarei UM ARTIGO POR SEMANA dessa série, a começar pela revisão do Grupo de Execução que ocorrerá até sexta-feira.

Bom que isso sirva de exemplo a todos, mesmo Gerentes de Projeto com experiência costumam errar, principalmente em projetos onde o “Cliente” não é muito exigente…

Anote isso no seu caderninho de lições aprendidas, pois como falei no artigo sobre planejamento: Shits happen !!!

TEXTO REVISADO.

Este artigo é parte de uma série de 5 artigos que apresentam os 5 Grupos de processo de Gerenciamento de Projetos descritos no PMBOK:

1. Iniciação - Define e autoriza o projeto ou uma fase do projeto..
2. Planejamento - Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.
3. Execução. Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.
4. Monitoramento e controle. Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.
5. Encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

O Terceiro artigo falaremos sobre Execução

O Grupo de processos de execução é composto pelos processos que tem por objetivo coordenar pessoas e outros recursos para realizar o plano do projeto gerado pelo grupo de processos de Planejamento.

Segundo informações que obtive (não tive acesso ao documento oficial ainda) no Draft da nova versão do PMBOK, versão 4 a ser lançada (espera-se) ainda em 2008 o Grupo de processos de execução está deixando de existir, sendo que os processos pertinentes estão sendo migrados para o Grupo de Processos de Monitoramento e Controle. Espero o lançamento oficial do PMOK 2008 para confirmar isso, mas gostei da novidade, uma das coisas com que nunca concordei plenamente com o PMBOK é existir esse grupo, pois a função do Gerente de Projetos é fazer com que o projeto ocorra conforme planejado,e não executá-lo. Quando ele faz isso (no caso, por exemplo, de um projeto de vida) ele deve usar “dois bonés”, o do executor e o do Gerente, como só tem uma cabeça deve usar um boné de cada vez.

Mas, como ainda falamos da versão 3 (ou 2004), existe esse grupo de processos, composto dos seguintes processos:

1. Orientar e gerenciar a execução do projeto

Anteriormente chamadod e Executar plano do projeto este processo visa garantir que o plano seja executado e que APENAS as atividades definidas no plano serão executadas. É comum gerentes iniciantes executarem atividades adicionais, para “agradar o cliente”. Ë claro que você pode agradar o cliente, mas no primeiro atraso gerado, ele esquece disso, e vai te cobrar. Conhece a história do Plantador de Arroz? Conto num outro artigo, em breve (afinal meu plano de projeto para o projeto de série sobre os grupos de processo não prevê essa atividade…*rs) . Esse é o único processo essencial, os demais são Processos facilitadores.

3. Realizar a garantia da qualidade

Eu não concordo com pessoas que dizem que um produto tem mais ou menos qualidade. Para mim qualidade é binário, ou sim ou não, ou tem qualidade ou não tem qualidade, isso porque qualidade é atender expectativas, portanto ou atende ou não atende (essa história de “atende parcialmente” é igual “parcialmente grávida”) Usa-se muito qualidade superior e qualidade inferior, isso define uma categoria, não a qualidade em si. Esse processo consiste em avaliar regularmente o desempenho geral do projeto, com o objetivo de satisfazer os padrões estabelecidos de qualidade (em outras palavras atender a expectativa).

3. Contratar ou mobilizar a equipe do projeto

Projetos são executados por pessoas (por enquanto, afinal, ainda não existem robots inteligentes), portanto por uma equipe (nem que seja uma equipe de uma única pessoa. No início desse projeto a pessoa pode “existir” ou não. Se existir voce precisa mobilizá-la, ou seja colocá-la em condições de trabalhar, isso envolve atribuir as atividades, fornecer as condições básicas e etc. Caso a pessoas não “exista”, é preciso contratá-la, antes de mobilizá-la.

4. Desenvolvimento da Equipe

É comum em projetos precisarmos de pessoas que assobiem e chupem cana, sem desafinar e ainda sirvam cafezinho…

Nem sempre as pessoas que dispomos ou conseguimos contratar, tem todas as habilidades necessárias, é portanto necessário desenvolver a equipe, ou seja, trabalhar o grupo para que as habilidades necessárias estejam presentes.
Sem isso, o projeto terá um desempenho deficiente.

5. Distribuição das Informações

Olha a comunicação ai geeeeeeeeeente!!! Já dizia o maior comunicador desse país, Abelardo Barbosa, o chacrinha: “Quem não se comunica se estrumbica”. Comunicar não é apenas falar, enviar a mensagem. Ë enviar a mensagem e garantir que isso seja entendido por todos os “Stakeholders”, não apenas os membros da equipe. Voltarei a falar sobre isso em um artigo futuro sobre Comunicação e Stakeholder.

6. Solicitar respostas de fornecedores

Em outras palavras solicitar propostas, informações, cotações, licitações, enfim, tudo aquilo que voce precia para comprar algo, se precisar comprar algo, é claro.

7. Selecionar de Fornecedores

Você já comprou algo no Mercado Livre de um vendedor com 0(ZERO) referencias? Por mais honesto que ele seja, e mesmo sendo o Mercado Livre e a maior parte dos vendedores idôneos, o numero de vendas e o percentual de satisfação garantem a entrega e a satisfação (a SuperLoja do Jobson só mostra produtos desses clientes, por isso estou criando uma…*rs). o mesmo cuidado ao comprar algo para seu projeto, principalmente se precisar de ume entrega programada, as vezes é melhor pagar mais caro do que ter o projeto paralisado por não receber o produto adequado de um fornecedor desconhecido.

OBS: É sempre bom alertar que esses processos são as MELHORES PRÁTICAS, nem todos são executados em todos os projetos. Novamente o PMBOK não é uma metodologia a ser seguida a risca, é “apenas” um guia de “conselhos”.

Alguns desses processos precisam ser melhor detalhados, e serão em artigos futuros.

Este artigo é parte de uma série de 5 artigos que apresentam os 5 Grupos de processo de Gerenciamento de Projetos descritos no PMBOK:

1. Iniciação - Define e autoriza o projeto ou uma fase do projeto..
2. Planejamento - Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.
3. Execução - Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.
4. Monitoramento e controle. Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.
5. Encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

O Segundo artigo falaremos sobre PLANEJAMENTO.

Ouvi uma vez de um Gerente de Projetos uma frase que é das mais verdadeiras relativa a Gerenciamento de Projetos e que tomo por lema é: “90% dos problemas de projeto, para ser conservador, poderiam ser evitados se tivéssemos feito um bom Planejamento em seu início”.

Muitos podem contrariar essa frase dizendo que imprevistos acontecem, que a lei de Murphy é implacável, ou como diriam os americanos em seu pragmatismo: “shits happen”…

Sim isso é verdade, acontecem mesmo, e com muita freqüência e é exatamente por isso que existe o planejamento, evitar que as shits aconteçam ou, pelo menos, ter uma resposta adequada quando acontecerem. Em outras palavras, a maioria dos imprevistos são previsíveis, e pode portanto ser controlados.

Já vi muito gerente de projeto iniciante dizendo, em listas de discussão : “Oi pessoal, estou começando a gerenciar um projeto e preciso de um ‘template’ de um Plano de Projeto, alguém pode me dizer onde baixar um ‘di-gratis’…”, como eu gosto de citações (mania de palestrante), costumo responder com apenas uma frase do Dwight D. Eisenhower (34º presidente dos EUA) : “Um plano não é nada, Planejar é tudo…”

Falar é fácil, eu tinha prometido escrever 2 artigos por semana sobre os Grupos de Processo do PMBOK, e na primeira semana, furei, escrevi apenas um… Pois é Shits happen…

Tive um problema de saúde, fiquei de cama na sexta, enfim, aconteceu um imprevisto, que poderia se previsto,a final todo mundo pode ficar doente, todo mundo pode sofrer um acidente, etc, etc…

Eu poderia ter previsto isso e ter escrito um artigo “de reserva”, assim, poderia simplesmente publicar e hoje estaria escrevendo o terceiro e não o segundo, como não fiz me resta REPLANEJAR: ou eu altero meu cronograma, atrasando a conclusão da série ou escrever 3 artigos essa semana e assim, cumprir o prazo final. É o que farei.

Só pra concluir o “prolegômeno”(adoro palavras difíceis…), sei que vão dizer, depois que acontece é fácil falar… Sim, realmente é, por isso recomenda-se que todo Gerente de Projetos tenha seu “caderninho” “lições aprendidas”, isso é uma entrada a mais no seu planejamento futuro, e assim as “shits” só acontecem uma vez…

Bom, mas vamos ao que interessa: PMBOK - Grupo de processos - Planejamento.

Para muita gente Planejar um projeto é criar um cronograma, funciona assim, você pega um template do MS-project, “chuta” quanto tempo gata para executar aquelas atividades que estão lá, coloca uma margem de segurança de 20 a 50%,e pronto, é só sair executando…

Se você planeja assim, um treinamento para ficar perfeito: Vá para a frente do espelho e comece a treinar o sotaque: shits happen, shits happen, shits happen. Isso tem que soar perfeito e natural quando você for expor o resultado do projeto.

Não sou maluco de dizer que o cronograma é inútil, um cronograma bem feito, uma boa planilha de riscos (falarei sobre riscos num artigo futuro) e uma dose cavalar de bom senso podem ser, muitas vezes, o suficiente para que o projeto tenha sucesso, mas o Cronograma e a Planilha de riscos são resultados do Planejamento,e não o planejamento em si.

O Grupo de processos Planejamento, do PMBOK contem os seguintes processos:

1 Desenvolver o plano de gerenciamento do projeto

O Objetivo deste processo é definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto.

2 Planejamento do escopo

O Objetivo deste processo é criar um plano de gerenciamento do escopo do projeto. Nele documenta-se como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto (ou WBS – Work Breakdown Struture) será criada e definida.

3 Definição do escopo

O Objetivo deste processo é gerar uma declaração do escopo detalhada do projeto. É um processo fundamental porque é muito comum recebermos demanda como Criar um relatório XYZ. E quando vai criar você verifica que as informações não existem, ai entra o JAQUES está fazendo o relatório, aproveita e faz uma tela para entrada de dados… JAQUES ta fazendo essa tela, faz a critica de validade… E por ai vai. Por isso : Detalhe o escopo. Parece a mesma coisa mas não é. Item o “cliente” pede, o item 2, o Gerente de Projetos diz o que precisa fazer para atender o item 1.

4 Criar EAP (ou WBS)

O Objetivo deste processo é subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.

5 Definição da atividade

Esse é fácil, o que eu preciso fazer para produzir o escopo desejado… (fácil de entender, de fazer, nem sempre…)

6 Seqüenciamento de atividades

Em que seqüência as atividades precisam ou podem ser executadas, quem depende de quem?

7 Estimativa de recursos da atividade

Qual o esforço que você precisa para fazer cada uma das atividades?

8 Estimativa de duração da atividade

Qual o tempo que você gasta para executar essa atividade com os recursos disponíveis.(ou pode acontecer o contrário, termos uma prazo fixo e variamos os recursos)

9 Desenvolvimento do cronograma

Deenvovler o cronograma do projeto a partir da análise das atividades, da seqüência das atividades, suas durações, e as necessidades de recursos (em outras palavras, de forma muuuuuito simplificada pega-se os itens 5, 6, 7 e 8 e coloca no Project).

10 Estimativa de custos

Aqui é que pega, quanto Custa???

11 Orçamentação

Detalhar o item anterior, ou seja COMO e QUANDO você vai gastar o orçamento.

12 Planejamento da qualidade

O Objetivo deste processo é identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los.

13 Planejamento de recursos humanos (montagem da equipe)

Conseguir que os recursos humanos necessários sejam designados e alocados ao projeto. Isso é complicado quando precisamos de profissionais de outras equipes, ou mesmo de outras empresas. ( O gestor quase nunca está disponível…).

14 Planejamento das comunicações

Estima-se que 90% do trabalho de um Gerente de Projeto, mesmo assim ATÉ o PMBOK relega essa atividade a um nível inferior, dedicando, na terceira edição) apenas 14 páginas de suas 405 ao assunto, ou seja meros 3,5%.

15 Planejamento do gerenciamento de riscos

O Objetivo deste processo é decidir como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.

16 Identificação de riscos

Riscos são eventos que podem alterar, para melhor ou para pior (Oportunidade ou Ameaça), a chance de sucesso do projeto. Este processo consiste em identificar esse prováveis eventos.

17 Análise qualitativa de riscos

Uma vez identificados os riscos, este processo visa priorizar riscos para análise ou ação adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto.

18 Análise quantitativa de riscos

O Objetivo deste processo é analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto.

19 Planejamento de respostas a riscos

O Objetivo desse processo é avaliar os processos 16, 17 e 18 para desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

20 Planejar compras e aquisições

Este é o processo necessário para determinar o que comprar ou adquirir e quando e como fazer isso.

21 Planejar contratações

Este é o processo necessário para documentar os requisitos de produtos, serviços e resultados e identificar possíveis fornecedores.

Como da pra ver são várias atividades alem de simplesmente montar um cronograma, mas como fazer isso?

O PMBOK não é uma metodologia, embora muitas empresas de treinamento vendam cursos sobre a “metodologia PMI”, a metodologia é o método que VOCÊ ou SUA EMPRESA usam para implementar esses processos.

Num próximo artigo vou apresentar UMA forma de planejamento que eu gosto (nem sempre é possível) usar.

PS. A figura acima é um diagrama de um Mapa Mental (MindMap), um diagrama usado numa técnica de planejamento que gosto muito. Voltareia falar no assunto e explicar seu funcionamento no futuro.