Projetizando a Vida

Infelizmente não sou Vidente, e como todo  Gerente de Projetos lamento profundamente isso, mas apesar disso, posso garantir que sei duas coisas  sobre o próximo projeto que vou assumir, embora não saiba qual será ele.

 E mais ainda, sei também duas coisas de Seu projeto atual e sobre seu próximo projeto, mesmo sem saber quais são eles, e nem mesmo sem saber quem é você… (e isso depois de dizer que não sou vidente!)

 Essas duas coisas são :

 1. O Escopo vai mudar

2. Alguma coisa vai dar errado…

 Pois é,  depois que parar de rir, pare e pense em todos os projetos que você já teve conhecimento, você vai ver que o escopo mudou, e alguma coisa deu errado.

 Chamo a isso de Verdades dos projetos, essas são duas verdades incontestáveis dos projetos, o Escopo muda, e algo dá errado …

 Mas se o escopo muda, porque que é que não acerta o escopo logo no início?  E porque não planeja melhor para evitar que as coisas dêem errado?

 A resposta é simples, é porque se você fizer isso vai gastar muito mais tempo no planejamento,  vai gastar muito mais esforço se precavendo contra problemas que não vão ocorrer, seu prazo e seu orçamento ficarão infinitamente maiores, e depois de tudo isso…

 Seu Escopo vai mudar mais uma vez, e alguma outra coisa vai dar errado…

 Afinal, essas são duas Verdades absolutas em Projetos.

 Quando falamos em Projetos estamos falando , por definição,  em algo que nunca foi feito antes,  pelo menos não EXATAMENTE daquela forma, afinal, “projetos são empreendimentos temporários que visam produzir um produto ÚNICO, a um custo pré-determinado”…

 São tantas variáveis envolvidas que é impossível controlar todas, por isso, algo vai dar errado, algum imprevisto vai forçar uma mudança de escopo, sem levar em conta o famoso Jaques… (já que esta fazendo isso…)

 Quando se fala em Projetos de TI então, temos um “complicômetro” a mais, é a nossa “matéria prima”…

 Se na engenharia a matéria prima é o cimento, o tijolo, o concreto, na Informática a “Matéria Prima” são as pessoas…

 Lidar com pessoas é uma das atividades mais difíceis de se aprender, ou você tem empatia ou não tem, ou o “santo bate” ou nada feito…

 Conheci um Gerente de Projetos, um dos Bons, que me dizia que o principal instrumento que ele usava era a Planilha de Riscos, pois com ela, ele conseguia controlar tudo, sem ela ele estava perdido…

 Um dia resolvi testar, e comecei a usar os meus “E SE…”

E SE o cliente mudar o escopo?

 Lá vai o Carlão, planilha de Risco, Item 5, Mudança de Escopo por parte do Cliente, Probabilidade Alta, Impacto Alto, Estratégia de Enfrentamento Triplo(Plano de aceitação ativa, Plano Mitigação e  Plano de Contingência): Plano de aceitação ativa- Incluir 5% de margem de segurança. Plano de Mitigação: Documentar Escopo Inicial e Negociações, Demonstrar alteração de Escopo ao Cliente e Renegociar.  Contingência: Estratégia de Compressão: FastTrack.

 E SE o programador fizer corpo mole?

 La vai o Carlão, Planilha de Risco, Item 9, Baixa Produtividade da Equipe pro Desmotivação…

 E assim por diante, peguei a Planilha de Risco dele e vi que tinha 95 riscos apontados, com as devidas estratégias de enfrentamento.

 Perguntei, quanto tempo ele “perdia” criando aquela planilha para cada projeto, ele respondeu: Perder? Nem um minuto… Investir? 1 dia…

 Antes que eu trucasse, ele falou, essa Planilha me acompanha há 10 anos, a cada projeto eu apenas ajusto as probabilidades e o impacto, eventualmente entra um ou outro, mas nunca sai nenhum, afinal, sempre tem escopo flexível, sempre tem custo apertado, cronograma inviável, profissionais insatisfeitos, etc., etc.

Projetos são empreendimentos únicos é  claro, mas o ser humano é sempre igual, e portanto, as empresas e o relacionamento entre elas são muito parecidos, assim como seus problemas, por isso, os riscos são sempre os mesmos, somente sua probabilidade e seu impacto é que mudam…

 E ele terminou com a frase sobre as verdades: Só sei duas coisas sobre meu próximo projeto: O Escopo vai Mudar e Alguma coisa vai dar errado. A única forma de conviver com isso é ter uma planilha de riscos muito bem montada.

 Logo depois dessa conversa montei a planilha do projeto que eu estava iniciando, apontei 22 riscos. Quando terminei o projeto ela tinha 35, Hoje ainda a carrego comigo, já tem 53.

 E Antes que alguém me peça a planilha, aviso que eu pedi a dele, e darei a mesma  resposta que ele me deu:  Mais importante que ter uma boa planilha de riscos, é construir uma planilha de riscos, construa a sua.

Voltarei a falar sobre Riscos em breve e criarei uma área de templates no Blog para deixar um modelo para quem quiser construir a sua, ok?

Alguns textos sobre riscos:

Por que ignoramos a gestão de riscos em nossos projetos? (GestaodeProjetos.net)

Analisando Riscos na Gerencia de Projetos (O Blog da Gerência de Projetos)

OBS: A Imagem acima é a capa do Livro Gerenciamento de Riscos em Projetos, da FGV, que recomendo a leitura e pdoe ser adquirido no Submarino, clicando aqui

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 !!!