Projetizando a Vida

Já trabalhei em Vários Projetos de em Empresas que tinham ou estavam implementando o CMMI e, invariavelmente, tive atritos com o “pessoal”  do CMMI.

Quem me conhece sabe que sou uma pessoa crítica, isso não quer dizer que sou “do contra”, que dizer apenas que não sou uma pessoa passiva, não aceito as coisas como elas são simplesmente por que são assim, quero saber porque são, isso faz parte do processo de aprendizado, pois somente assim podemos melhorar as coisas, e acredito que é assim que um Gerente de Projetos deve se portar, invariavelmente, entender as coisas, antes de aceitá-las ou recusá-las.

Mas voltando aos meus atritos com o “pessoal do CMMI”,  bom o primeiro atrito é com a existência de um “Pessoal do CMMI”, apesar “deles”acharem que sou contra o CMMI, sou um dos maiores entusiastas do CMMI, desde que sua implementação seja verdadeira, e para que ela seja verdadeira, ela deve ser implementada pela empresa toda e não pelo “pessoal do CMMI”, portanto sua existência já é, a meu ver, um sinal de algo errado, em segundo lugar na maioria dos locais onde vi sua implementação percebi um erro conceitual importantíssimo e por isso fui um crítico duro.

O CCMI, para quem não conhece é, a grosso modo,  um modelo que define a maturidade dos processos de desenvolvimento de software. Ele define 5 níveis de maturidade sendo que o nível 1 significa TOTALMENTE IMATURO, ou seja Caos Total, ou processos inexistentes, portanto o CMMI inicia-se no nível 2- Processos Repetitivos, passa pelo Nível 3 - Processos Definidos, Nível 4 - Gerenciado e finalmente Nível 5 - Otimizado.

Não existe uma obrigatoriedade das empresas escalarem os níveis 2, 3, 4 e 5, uma empresa pode (se for louca o suficiente, e trabalhei em uma que tentou isso) implantar direto o nível 5, normalmente as empresas iniciam na 2, escalam para a 3 e então pulam para a 5 (não conheço nenhuma  que tenha tirado o nível 4).

O grande problema quando se cria a “Turma do CMMI”  é que normalmente não existe ninguém da “Turma de Gerentes de Projeto” nesse grupo e “pequenos”  erros conceituais costumam acontecer.

O Pior deles é muito comum: O Objetivo do CMMI é PADRONIZAR PROCESSOS, e o que muitas vezes acontece é que as empresas acabam padronizando PRODUTOS. Ou seja, tornar os produtos IGUAIS.

OPS… Vamos fazer um Rewind, retomar a definição de projeto: “Projeto é um empreendimento TEMPORÁRIO que tem por objetivo produzir um PRODUTO ÚNICO, com um ORÇAMENTO previamente definido.”

Se vamos produzir PRODUTOS ÚNICOS, como é que vamos fazer PRODUTOS IGUAIS???

Podemos concluir que CMMI e Projetos são incompatíveis? Não, de forma alguma. O que podemos concluir é que precisamos envolver Gerentes de Projetos EXPERIENTES na definição dos processos de implementação do CMMI ou pelo menos permitir que os mesmos critiquem os mesmos durante a sua implementação, sem que sejam considerados anti-CMMI.

Vou Abrir uma categoria nova para os Textos do CMMI e voltarei a falar, futuramente, sem uma freqüência pré-determinada,  sobre cada um dos Processos, fazendo um paralelo sobre os Processos/Grupo de Processos do PMBOK.

Existem alguns documentos que deveriam ser tratados com mais seriedade, não apenas, mas principalmente em projetos, mas especificamente em projetos um dos documentos mais desprezados é o  Project Charter, ou o termo de Abertura do Projeto.

Quando terceirizamos um Projeto normalmente esse documento é feito, pois como praticamente todas as metodologias dizem que ele é obrigatória, ele consta no contrato, e portanto ele é feito, mas muitas vezes é feito “nas coxas” e na grande maioria das vezes (aprendi a nunca falar SEMPRE) ele é feito e depois ignorado, a menos que se tenha auditorias freqüentes (por exemplo de CMMI) quando então se lembra que ele existe, mas apenas isso…

Quando se fala num Projeto Pessoal então, ele é praticamente inexistente…

E não são apenas Gerentes iniciantes esquecem dele, querem um exemplo prático?  Esse blog não tem um Project Charter…  Ops!!! *rs

Pois é, e sua falta acabou trazendo problemas, por isso ele ficou abandonado um tempão, mas agora que resolvi retomá-lo, e com força total, começarei como deveria ter começado, farei um Project Charter (o nome em inglês parece impor mais respeito…*RS),  ele será colocado numa página a parte, em breve, ma hoje quero falar livremente sobre o que me levou a isso…

Por não ter esse plano o blog fugiu do controle, acabei seguindo o PMBOK a risca, nada contra ele, mas isso, além de deixar o blog ligeiramente chato  é desnecessário, existe o próprio PMBOK para isso, além de centenas de outras fontes,  vou finalizar a serie sobre o grupo de processos para não deixar algo inacabado,  mas tomarei outra linha daqui pra frente (que será refletida no Project Chart),  falarei sobre técnicas, metodologias e ferramentas, sobre situações práticas e meu objetivo será criar uma comunidade de Gerenciamento de Projetos, para isso abrirei o blog para outros Gerentes de Projeto que desejarem escrever, estou planejando um Forum de Discussões e mais alguns elementos para Transformar o Projetizando em uma Comunidade.

A Primeira Ação nesse sentido foi o lançamento do Domínio próprio:  PROJETIZANDO.COM.BR, este post está sendo replicado neste domínio e no domínio antigo projetizando.blgoprofissional.com.br, que a partir de agora deixa de ser o domínio principal, como ainda  tem bastante assinantes de feeds, postarei resumos periódicos, mas sempre direcionando para o novo endereço…

Enfim, esperem bastante novidades e muita informação em 2009.

Bons Projetos para todos.

Quando se fala sobre Projetos, estamos falando de um empreendimento temporário, que visa a produção de um produto único.

Hora, se vamos Gerenciar um Projeto, o que vamos fazer?

Vamos controlar e qeuilibrar 3 grandes variáveis:

Escopo

São as exigências especificadas para o resultado fim, ou seja, o que se o produto a ser produzido. Isso deve ser extremamente bem detalhado, para evitar problemas, por exemplo, Produzir um Carro. Ele precisa ter carroceria, rodas, motor, acabamento. Apenas isso? Não, o motor tem infinitas peças, O Acabamento muito mais, e os itens de segurança, e… enfim, muita coisa.
E é preciso ter um cuidado de controlar os detalhes, principalmente quando várias pessoas estão trabalhando, tem muita gente que quer fazer “Melhor do que foi pedido”e isso pode (e normalmente é) um desastre.
Imagine o seguinte, o cara que vai fazer os faróis acha que ao invés de fazer o farol com determinado desenho pode fazer algo melhor, mais bonito, que aproveite melhor a luz, melhorando a segurança… O único problema é que não vai encaixar na carroceria, mas que ficou mais bonito ficou…
Parece piada, mas que já usou fábrica de software em projetos de TI sabe o que estou dizendo…

Tempo

Se o projeto é temporário, tem um tempo para ser executado e atrasar o projeto é algo normal,e muitas vezes o resultado é uma calamidade.
Um exemplo: Seu projeto é montar uma vitrine para uma loja de presentes par ao natal. Você monta uma vitrine fantástica, a melhor do mundo, ninguém vai olha r para ela e resistir a comprar o que está lá. Sucesso? Depende, se ficou pronta no dia 26/12…

Custo

Esse é um dos principais problemas do Gernete de Projeto, pois raramente temos condições de negociar muito isso, principalmente em emrpesas que vendem o projeto ao cliente sem consultar o Gerente de Projetos, ou quando somos contratados para tocar um projeto já iniciado…
Pior ainda só aqueles projetos em que dizem: RECURSOS ILIMITADOS, o que você precisar, você terá…
Sobre isso, si tenho uma coisa a dizer, uma dica infalível: É MENTIRA !

Vamos pensar em alaguem que tem recursos ilimitados, o melhor Gerente de Projetos que existe, com capacidade de fazer um projeto monstruoso gigantesco num tempo extremamente…
Sabem quem é esse Gerente? Não? Vou dar uma dica: O prazo eram 7 dias…

Provavelmente já sabe, mas vou pedir desculpas aos Ateus e aos Evolucionistas (eu sou evolucionista) e usar a teoria do Criacionismo para explicar.
Estou falando de Deus, onisciente, onipresente e onipotente (3 características que facilitariam muito a vida de um Gerente de projeto).
Em apenas 7 dias, na verdade 6, pois como o cronograma adiantou, ele descansou no sétimo (novamente mais um sonho dos Gerentes de Projeto).
Mesmo com todos os recursos, ele precisou improvisar (a mulher precisou ser feita de uma costela…).
E com todos esse poder, com todos esses recursos, ele não conseguiu convencer todo mundo, afinal, existem muitos Ateus e Agnósticos no mundo…

Obviamente você não é Deus (se for e estiver lendo meu blog, deixa um comentário e divulgue o blog em sua “esfera de influência, eu agradeço antecipadamente…), por isso, seus recursos são limitados sim, por maiores que eles sejam…

Alguns autores falam numa quarta variável A QUALIDADE.

Eu sigo alinha de que não existe uma variável qualidade, pois qualidade não é variável, é algo binário SIM ou NÃO: ou tem ou não tem.

QUALIDADE é atender as expectativas, e quais são as expectativas que um Geente de Projetos tem que atender?

Entregar o produto como foi solicitado(Escopo) no Prazo acordado(Tempo) com o Orçamento (Custo) previsto.

Ou seja: Qualidade é obrigação e não Variável.

Essas 3 variáveis formam o “Triangulo de Ferro”do Gerenciamento de Projetos, e cuidado, é IMPOSSÍVEL mexer em um dos lados do Triangulo sem mexer em PELO MENOS um dos outros dois, muitas vezes sem mexer NOS DOIS.

Um Exemplo:

Seu projeto é cavar um posso de 1 metro de diâmetro, 3 metros de profundidade em uma semana e tem 2 homens (custo = salário dos dois homens).

E Ai você tem as solicitações:

• 1. Dá pra fazer um poço de 6 metros? Dá sim, se eu tiver 2 semanas ou 4 homens.
• 2. Dá Pra fazer em meia semana? Dá, se eu tiver 4 homens ou fizer um poço de 1 metro e meio
• 3. Dá pra eu fazer com um homem só? Dá, se eu tiver 2 semanas ou fizer um poço de 1 metro e meio

Mas CUIDADO.

Essas alterações nem sempre são lineares, imaginem 4 homens trabalhando num buraco previsto para 2. Pode haver perda de produtividade, e ai, novamente, mexe nas variáveis.

Voltarei a falar do assunto num artigo sobre CRONOGRAMAS.

LEia mais no Blog Reflexões Digitais

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.