Entendendo os processos de qualidade do PMBOK

abril 21, 2010 4 comentários

É grande a confusão que muitas pessoas fazem em relação aos processos de Gerenciamento da Qualidade presentes no PMBOK (e o pior é que tem gente fazendo mais confusão ainda na hora de explicar). Como em de praxe aqui no “Falando em Projetos”, vamos direto ao ponto.

O PMBOK contém 3 processos ligados à qualidade: (1) Planejar a qualidade, (2) Realizar a garantia da qualidade e (3) Realizar o controle da qualidade. Primeiramente vamos esclarecer as diferenças entre os processos (2) e (3).

Já vi controle de qualidade e garantia da qualidade serem tratados como sendo a mesma coisa VÁRIAS VEZES. Creio que isto ocorra porque qualidade é uma área bastante vasta, que transcende o gerenciamento de projetos, e não há uma terminologia totalmente padronizada entre as diversas publicações que tratam do tema. E como não há uma referência absoluta e única, há uma tendência a se usar o tema Garantia da Qualidade pra tudo, já que ele parece mais “poderoso” e menos  propício à resistência. Controle não é lá uma palavra muito atrativa, não é mesmo?

Entretanto, do ponto de vista do PMBOK, a diferença é muito clara:

  • Garantia da Qualidade é a verificação de que as políticas, os processos e os procedimentos definidos para o projeto estão sendo devidamente utilizados. Preocupa-se também com a melhoria contínua destes ativos de processo.
  • Controle da qualidade é a verificação de produtos gerados pelo projeto, a fim de checar se estão em conformidade com os padrões de qualidade definidos.

Visto de outra forma: se estou testando um produto, ou fazendo algum tipo de inspeção sobre um produto (resistência de contreto, por exemplo), estou realizando controle de qualidade. Se estou fazendo uma auditoria de processos, estou realizando a garantia de qualidade.

Pra fechar o trio, o processo Planejar a qualidade cuida de definir os diversos ativos de processo e padrões que deverão ser seguidos no controle  e garantia da qualidade. E algumas “otras cositas mas”, tais como a frequência com a qual as inspeções e auditorias vão ocorrer, critérios de amostragem, responsabilidades em relação à qualidade, etc.

Importante: pra quem vai fazer a prova de certificação PMP, entender estas diferenças é FUNDAMENTAL.

5 objetivos pra não esquecer

março 29, 2010 Deixe um comentário

Ron Holohan resumiu de forma prática em seu post “The 5 goals of a Project Manager” o que ele pensa serem as principais metas a serem alcançadas pelos GPs em seus projetos.

Como tem muita coisa escrita sobre gerenciamento de projetos atualmente e pouco tempo para a maioria das pessoas lê-las, gosto de textos focados assim que de forma suscinta nos direcionam para o que realmente é importante. Categorizo os 5 pontos de Holohan em 2 grupos principais. O primeiro grupo, com os três primeiros pontos, trata do básico:

Objetivo 1: Terminar no prazo

Objetivo 2: Terminar dentro do custo

Objetivo 3: Atender aos requisitos

A boa e velha tríade escopo / tempo / custo (com boa vontade de quem quer simplicidade, daria pra incluir a variável qualidade no objetivo 3).

O segundo grupo, com os dois últimos pontos, já aborda uma questão muitas vezes esquecida pelos GPs: a REAL satisfação de todas as partes interessadas com o projeto. Veja:

Objetivo 4: Mantenha os clientes felizes

Objetivo 5: Assegure-se que seu time está feliz

Nesse grupo aparece o que está além do contrato, da mera formalidade.  Aquilo que é importante, menos para garantir o pagamento pelo projeto corrente, mas fundamentalmente para aumentar as chances de sucesso em novos projetos (no caso dos clientes até mesmo para viabilizar a existência de um novo projeto).

De que adianta atender aos requisitos escritos se as reais expectativas dos clientes não estão devidamente expressas e resolvidas? Será que vale a pena esconder alguns problemas dos clientes só pra parecer que tudo está bem (felicidade vai passar longe quando ele descobrir)? E o seu time: será que finalizar em dia, dentro do custo, com tudo atendido mas com a equipe em farrapos é algo realmente bom? Estas pessoas vão querer trabalhar com você no futuro?

São dois pontos simples, mas esquecidos pelo fato de não se traduzirem na letra fria dos contratos, das especificações. Ou melhor: eram esquecidos. Já gravou na memória, né?

Categorias:Na prática, Soft skills

Turbine o gerenciamento de seus projetos com novas tecnologias

março 26, 2010 5 comentários

Passeando pela web durante a madrugada encontrei um guest post excelente de Andrew Filev no blog “A girls guide to Project Management”. Nest post, Andrew mostra a importância das mídias sociais em GP por meio de duas histórias de gerentes de projeto com rotinas bem diferentes. Ambos trabalham nos EUA e gerenciam projetos para clientes na Europa. Veja abaixo como é a vida destes caras.

Jake

Jake, um dos gerentes de projetos, está sempre muito ocupado. Sua rotina diária é composta das seguintes atividades:

  • Checar e-mails logo no início da manhã para obter as atualizações do projeto pelos diversos membros da equipe;
  • Ligar, enviar e-mails ou encontrar-se pessoalmente para coletar novas informações do projeto e garantir que tudo vai bem;
  • Atualizar o plano de projeto com todas as informações obtidas;
  • Gerar relatórios de status para os diversos executivos da empresa;
  • Comunicar-se por e-mail ou telefone com o cliente que está em Londres;
  • Resolver uma série de problemas que aparecem no projeto por meio do telefone, reuniões e e-mails;
  • Lidar com a confusão de se ter várias versões de documentos do Word e do Excel.

As pessoas do time de Jake também são bastante ocupadas e enfrentam alguns problemas.Veja:

  • Eles recebem entre 50 a 100 e-mails por dia que precisam ser checados necessariamente;
  • Eles não têm acesso direto ao plano de projeto. Assim, se eles precisam reportar progresso em suas atividades eles precisam enviar um e-mail para Jake.

Às vezes eles perdem ou se esquecem de itens importantes, mas isto não é um grande problema já que Jake sempre pode ligar para eles para lembrá-los. 🙂

Jake é um excelente GP e adora seu trabalho. Ele trabalha arduamente para manter tudo em ordem, mas raramente tem tempo para pensar em sua estratégia de gerenciamento de projetos ou sobre a motivação de seu time e normalmente depende de horas extras para completar se trabalho. Mas, fazer o que? Vida de GP não é fácil, não é mesmo?

Simon

Simon, o outro gerente de projetos, tem uma rotina diferente. Veja as características do seu trabalho e de sua equipe:

  • Simon checa o e-mail pela manhã, mas a quantidade de mensagens recebidas não passa de 10 a 15;
  • Sua equipe também não precisa trocar dezenas de e-mails já que eles utilizam um sistema de gerenciamento de projetos baseado na WEB, em que todos podem observar o progresso dos projetos on-line (inclusive os representantes do cliente em Barcelona e os executivos da empresa). Além disto, os próprios membros da equipe do projeto podem atualizar suas tarefas diretamente, garantindo uma maior aderência do plano de projeto com a realidade.
  • Logo no início do trabalho, Simon criou um blog do projeto e compartilhou por meio dele a sua visão sobre o desenvolvimento do projeto com sua equipe. Os membros da equipe se sentiram encorajados, e além dos feedbacks aos posts de Simon passaram também a contribuir com sugestões para melhorar o andamento do projeto. Todos recebem as atualizações por meio de feeds RSS e podem usar recursos de tags e buscas para encontrar rapidamente qualquer tópico de interesse que eventuamente tenha sido discutido;
  • Simon não costuma usar o telefone. Ele prefere o Skype, já que além de voz a ferramenta integra também funções de chat e video-conferência. Reuniões diárias de 15 minutos são executadas envolvendo pessoas da equipe em 3 cidades distintas dos EUA e o cliente em Barcelona;
  • Simon gosta de ferramentas de instant messaging, mas acredita que elas não são ideais para sua equipe. Uma aplicação de microblogging mostrou-se mais adequada. Membros da equipe a utilizam para dizer no que estão trabalhando, fazer perguntas, compartilhar links e solicitar ajuda em algum problema específico. A possibilidade de fazer tudo isso pela Internet tem sido algo muito útil para um time distribuído em 4 fusos horários diferentes;
  • Simon náo tem problemas com versões de documentos, já que toda a documentação é gerada em um Wiki.

Simon também é um profissional muito ocupado. Ele está sempre pensando nas próximas etapas do projeto e em como motivar sua equipe. Ele investe também boa parte de seu tempo nos relacionamentos com todos os envolvidos em seus projetos e até fez bons amigos entre clientes e colegas de time. Alguns deles são seus amigos ou contatos em redes como Facebook e Linkedin. Sua equipe é menos estressada que a de Jake, já que tem menos problemas de comunicação e como consequencia comete menos erros. Todos se sentem parte de uma grande comunidade, a despeito de estarem tão distantes fisicamente uns dos outros. O resultado: expectativas do cliente sempre superadas!

Simon não liga muito para buzz words tais como WEB 2.0 ou “mídias sociais” e não se preocupa em sempre seguir a última tendência. Apenas não tem medo de experiementar o novo. Alguns destes experimentos invariavelmente têm se mostrado extremamente úteis para a execução de sua função como gerente de projetos.

E VOCÊ?

Agora pense (30 segundos apenas): Que tipo de profissional tem mais valor? Jake ou Simon? Que tipo de profissional VOCÊ quer ser?

Aprenda estes conceitos e pare de brigar com seu chefe!

março 24, 2010 2 comentários

Em termos bem simples, uma estimativa é uma previsão referente ao esforço gasto,  custo ou duração de uma atividade ou projeto.

Uma meta é uma definição de um objetivo de negócios desejável.

Um plano é uma forma  de se atender às metas.

Perceba então: são coisas completamente diferentes, apesar de correlatas!

O processo de estimar é analítico e não viesado e busca acurácia, correção dos números. Baseado em experiência e dados históricos eu tento prever com a mínima margem de erro, o quanto eu gastaria ou quanto demoraria um projeto.

Já o processo de planejar é viesado por natureiza. O objetivo de um planejamento é criar uma rota para se atingir metas, levando em consideração as minhas estimativas.

Estas diferenças são  motivo de desentendimentos terríveis entre gerentes de projeto e executivos. Imaginem o seguinte diálogo:

Executivo: Quanto tempo você acha que o projeto demorará? Precisamos do software em 3 meses.

Gerente de Projetos: Vou avaliar e te dou a resposta em algumas horas…

Depois de analisar seus números…

Gerente de Projetos: Estimamos que o projeto levará 5 meses.

Executivo: 5 meses? Você é surdo? Eu disse que preciso do software em 3 meses.

Agora repare: o executivo solicitou uma estimativa mas na realidade queria um plano para atender à sua meta de negócios (ter o software em 3 meses). O gerente de projetos fez o que lhe foi mandado, mas acabou ouvindo poucas e boas de graça porque não soube como lidar com um executivo.

Da próxima vez em que isso lhe acontecer não faça apenas o que lhe foi solicitado. Entenda que seu executivo quer algo mais. E faça o possível para ter um plano factível. Tente negociar o escopo, entenda a real necessidade de se cumprir a meta, e negocie condições mínimas para que seja possível se atingi-la. É claro que, se a diferença entre sua estimativa e a meta for muito grande, o plano tende a ser de altíssimo risco e talvez não valha a pena ir adiante. O melhor seria flexibilizar a meta. Mas você só vai conseguir negociar se mostrar capacidade e conhecimento de causa.

As definições e o diálogo hipotético foram retirados do excelente livro Software Estimation de Steve McConnell. Pra quem se interessa pelo assunto “estimativas”, recomendo fortemente a leitura.

Categorias:Na prática

Dessa vez as más nóticias não vieram de um “Chaos Report”

março 23, 2010 2 comentários

Um estudo recente conduzido pela KPMG e PMI na índia identificou que, de uma amostra de 1035 projetos de infra-estrutura executados entre 1992 e 2009:

  • 82%  terminaram fora do prazo;
  • 41%  custaram mais que o planejado.

Percebam que a fonte dos dados não é mais o famoso Chaos Report que há vários anos vem expondo as mazelas dos projetos de TI. A pesquisa revela problemas em projetos de infra-estrutura, mostrando que, de modo geral, tem muita gente mandando mal em empreendimentos nos mais diversos mercados.

Na opinião dos entrevistados, o motivo das falhas nestes projetos foram principalmente:

  • mudanças frequentes nas especificações / design;
  • atrasos em aprovações regulatórias (o bom e velho governo dando a sua mãozinha);
  • planejamento fraco gerando, entre outras coisas, uma má utilização dos recursos.

O estudo mostrou também que 85% dos projetos que estavam dentro do orçcamento contavam cm uma estrutura de apoio similar a um PMO.

Processos mais estruturados  e capacitação de pessoas em gerenciamento de projetos não resolvem todos os problemas. Mas  parecem estar ajudando de alguma forma. A reportagem completa pode ser vista aqui.

Categorias:Uncategorized

Não subestime o poder de um “Kickoff”

março 22, 2010 3 comentários

Documentos de projeto bem escritos ajudam. É bom ter um  Plano de Gerenciamento de Projetos bem fundamentado. Mas é bom saber também que muita gente envolvida no seu projeto não tem lá muita paciência pra ler estas coisas. Nada melhor então que uma reunião de início de projeto (ou kickoff meeting) para alinhar as expectativas de todos. O blog The.Project.Management.Hut escreveu um post sugerindo alguns tópicos a serem incluídos na apresentação a ser realizada no kickoff meeting. Veja:

  • Nome do Projeto
  • Gerente do Projeto
  • Escopo
    • Objetivos
    • Clientes
    • Resultados Esperados
  • Estrutura
    • Time
    • Patrocinador
    • Outros Stakeholders relevantes
    • Estrutura Organizacional
  • Cronograma
    • Fases
    • Marcos
    • Deadlines
  • Participação do cliente
    • O que o cliente fará?
    • Como será a interação com ele?
  • Riscos e oportunidades
    • O que pode dar errado?
    • Quais as oportunidades e sinergias?
  • Orçamento
    • Quanto dinheiro?
    • Quanto esforço?
  • Reportes e reuniões
    • Como o progresso será reportado? (Muito importante)
    • Serão necessários encontros regulares?
    • Como problema e questões são levantadas? Pra quem?
  • Outros assuntos
    • Que ferramentas, etc estão à disposição?
    • Que plataformas / tecnologias serão utilizadas
    • Que dados ficam armazenado onde?

Seja simples! Todos à sua volta agradecem!

Relacionamento: a chave para uma carreira de sucesso.

março 19, 2010 2 comentários

Interessante a história descrita por Jim de Piante (gerente de projetos da IBM)  no blog Voices on Project Management mantido pelo PMI. Apesar do aparente sucesso em sua carreira (que incluía entre outras coisas uma experiência internacional recente de 2 anos), Jim conta ter sido pego de surpresa por uma demissão.

Jim resolveu então fazer algo no mínimo interessante: escrever em uma folha de papel as coisas que ele deveria ter feito de forma diferente para que tal situação não tivesse acontecido (e para que ela não se repetisse no futuro).  Todas as frases deveriam começar com “eu desejaria…”. O curioso é que NÃO apareceu nenhuma frase do tipo:

  • eu desejaria ter sido melhor no desenvolvimento de Gant Charts;
  • eu desejaria ter sido um desenvolvedor de software melhor;
  • eu desejaria ter aprendido mais sobre earned value analysis.

Mas vários itens ligados a RELACIONAMENTO estavam lá.

Conhecimentos técnicos são importantes. Mas você trabalha com outras PESSOAS. Para outras PESSOAS.

Não se esqueça disto.

“Falando em Projetos” com o PMI-SP

março 18, 2010 Deixe um comentário

Em dezembro de 2009, tive a honra de ser convidado para uma entrevista ao PMI-SP,  capítulo do PMI do estado de São Paulo. Para quem esté estranhando o nome, capítulo é a tradução literal para Chapter, uma seção regional do PMI em algum lugar do mundo.

Foi uma honra mesmo, dado que o PMI-SP:

  • é o maior capítulo do Brasil;
  • o décimo maior capítulo do mundo;
  • o terceiro maior capítulo do mundo fora dos Estados Unidos;
  • o capítulo que mais cresce no mundo atualmente.

Quem quiser saber um pouco mais sobre minha idéias, trabalho e histórico no mundo do gerenciamento de projetos, pode ver a entrevista na íntegra aqui.

Categorias:Entrevista

Padrões não são times de futebol!

março 17, 2010 4 comentários

“PMBOK é teórico.”

“Scrum é incompleto.”

“MPS.Br / CMMI é burocrático.”

“Prince2 é para os europeus.”

Confesso que às vezes, frases desse tipo me cansam.

Opiniões radicais em relação a padrões, metodologias, frameworks ou qualquer texto que se proponha a nos ajudar a gerenciar melhor nossos projetos NÃO costumam nos ajudar em NADA. Você não deve fidelidade a nenhum deles. Ao contrário do time de futebol de coração, você não precisa ter somente um.

Minha sugestão:

  • conheça melhor as abordagens;
  • entenda o que elas podem trazer de bom ou ruim para os seus projetos / sua empresa;
  • aplique o que fizer sentido e jogue fora o resto.

E vá expressar a sua paixão no estádio, que é mais divertido!

Em tempo:

  • sou instrutor em cursos de PMP;
  • implementador e avaliador MPS.Br;
  • uso abordagens ágeis em minhas consultorias;
  • e não me sinto nem um pouco mal com isso! Você também não vai se sentir, acredite.

Radicalismo está fora de moda. 🙂

Categorias:Comportamento

Começou um projeto e parou no meio do caminho? Cinco passos pra recomeçar.

março 16, 2010 2 comentários

Você iniciou um projeto pessoal, cheio de energia, e alguns dias (ou semanas, ou meses) depois, simplesmente parou. Como recomeçar? O blog Dumb Little Man descreveu um passo a passo para lidar com a situação. De forma resumida a proposta é:

  1. Decida se vale à pena de fato continuar. Você pode ter começado a escrever um blog para descobrir que odeia escrever. Ou que aprender um instrumento musical é muito mais difícil do que o esperado inicialmente. Se não vale apena, encerre o projeto de alguma forma em definitivo. Alivie o peso que isto pode ter em sua mente. Escreva um post de despedida no blog, venda a guitarra, mate a idéia em definitivo.
  2. Se for adiante, dedique um tempo considerável de tempo na retomada. A inércia (que você aprendeu nas aulas de física) existe, acredite. Não tente sair do lugar gastando 15 minutos por dia inicialmente. Gaste seu fim de semana.
  3. Defina uma data final. Um projeto sem previsão de término não é um projeto, não é mesmo? Provavelmente seu projeto parou porque você não estava trabalhando de forma consistente. E isto vai ocorrer de novo se não houver um deadline.
  4. Defina um cronograma. E claro, siga este cronograma. Defina quantas horas por semana serão dedicadas e em que momento elas serão trabalhadas (segunda à noite, domingo de manhã, etc). Defina marcos intermediários em intervalos de tempo regulares.
  5. Comprometa-se publicamente. Conte para um amigo, publique algo em seu blog, combine algo com alguém que dependa do fim do seu projeto (um exemplo pessoal meu: uma banda antiga que eu tinha só voltou a tocar quando me comprometi a “animar” a festa de aniversário de um amigo). Isto te ajudará a não parar de novo. E você já resolveu que vale a pena continuar, certo?

Agora faça um exercício: em que um projeto pessoal e um projeto corporativo se parecem? Em que eles são diferentes? Comente aqui, logo abaixo.

PS: Pra você, que é de BH:  hoje é o último dia para inscrições com desconto no preparatório PMP.  Aproveite! Caso se interesse em participar clique aqui.

Categorias:GP em nossas vidas