Blog Mundo PMP

Os desafios diários dos gerentes de projeto

2017-05-24T18:00:00.000-03:00

Depois de alguns anos afastado do gerenciamento de projetos - foquei minha carreira na gestão de serviços durante os últimos 4-5 anos - tive a oportunidade de voltar ao mundo do gerenciamento de projetos.
Confesso que já estava sentindo falta da rotina desta profissão: metas e entregas, conclusão de etapas (e comemoração por elas), enxergar o fim do projeto se aproximando são coisas que costumam motivar aqueles que escolheram, de fato, essa profissão. Comigo, pelo menos, é assim que a coisa funciona.

Não deixei de participar de fóruns e grupos de discussão relacionados a gerenciamento de projetos, e uma discussão, em particular, me chamou a atenção: era um professor meu, da FGV, comentando sobre problemas que estava encontrando em uma de suas consultorias, e muitos deles relacionados a gestão de tempo e cronograma do projeto.

Não é raro ver que muitos GPs ainda consideram que a maior parte do tempo que investem nos seus empregos é relacionado à manutenção de cronogramas. Apesar de ser algo comum, não pode ser considerada uma boa prática de gestão de projetos. O cronograma deveria ser o resultado de um trabalho, não o trabalho em si.

Criar um cronograma realista é, na imensa maioria das vezes, um enorme desafio para o GP. Se você pensou que isso se deve à complexidade de inserir e gerenciar o Project (por exemplo), você está enganado... Normalmente os cronogramas nascem de necessidades de negócio específicas: uma venda para um cliente que tem prazo para entrega, uma determinação do BACEN para uma instituição financeira, uma nova legislação que tem prazo fixo para entrar em vigor, um cliente exigente que já vendeu uma ideia de resultado e agora busca quem implemente seu sonho (em alguns casos, seu devaneio...). Esta é a maior dificuldade: fazer o trabalho do projeto caber no cronograma, que já sai com uma data de conclusão preenchida por outras pessoas, muitas vezes sem qualquer participação do GP ou dos grupos executores.

Some a isso a questão de recursamento do seu projeto e lembre-se que, no Brasil, a grande maioria das empresas é baseada em uma estrutura funcional rígida, ou com pouca flexibilidade, em que os GPs irão "disputar" os recursos humanos com as áreas operacionais. Nessa "briga" quem normalmente perde é o projeto, e não a operação (este é tema para o próximo post).

Então, se você está sofrendo para colocar seu cronograma em dia, faça as seguintes perguntas a si mesmo, talvez encontre a real causa da sua aflição:

Meu projeto já tem uma data de conclusão acordada, sem o meu consentimento

Se a resposta é SIM, então você já sabe que parte dos seus problemas com gestão de tempo não são causados diretamente pelo projeto em si, mas pela falta de planejamento adequado de quem tomou as decisões antes do plano.
Nesses casos, a melhor solução é entender os motivos que estão por trás dessa decisão. Não adianta lutar contra ela, pois, no pior dos casos, ela foi tomada com base em uma necessidade do negócio e dificilmente poderá ser mudada (ao menos no papel).

Obtenha um bom sponsorship para o projeto: o sponsor certamente poderá te ajudar a obter mais recursos, sejam eles materiais ou humanos, de forma a cumprir com a maior parte do plano.
Negocie entregas parciais: negocie, sempre que possível, a entrega de funcionalidades básicas que permitam a operação para a data acordada, e tente deixar para uma segunda onda os refinamentos e melhorias do projeto, pode ser uma saída para cronogramas impossíveis.

Eu errei no planejamento, sendo otimista demais com algumas tarefas

Esse é o tipo de erro que mais costuma ser associado com as falhas diretas do GP, mas nem sempre isso é verdade. Se o devido cuidado foi tomado, o plano deve ter sido criado com apoio de especialistas no produto que o projeto está entregando, então a responsabilidade pelo planejamento excessivamente otimista, ainda que seja do GP, pode ser compartilhada com a equipe de planejamento/design.

Isso resolve o problema? De maneira nenhuma. Mas dá ao GP alguma margem para negociar uma maior dedicação dos times funcionais, através de acordos com os times de design.

Obtenha sponsorship adequado: mais uma vez, é uma coisa vital e fundamental para todo projeto. Seu sponsor pode e deve te ajudar a obter recursos para o projeto, pois o interesse em vê-lo implementado é dele também. Se você não tem, ou não identificou um sponsor forte, reveja seu mapa de stakeholders e localize qual deles é o mais interessado nos resultados do projeto, compartilhe os riscos e as alternativas de redução de prazo.
Mapeie todos os riscos sempre que precisar revisar e comprimir o cronograma: toda compressão traz consigo o risco inerente da pressa, e como sabemos, ela sempre foi inimiga da perfeição. Aponte os eventuais atrasos que podem ocorrer ao cronograma caso os riscos se tornem problemas reais. Aja antes dos riscos se tornarem problemas e compartilhe as expectativas reais com seus stakeholders.
Adote o conceito de right first time: evite retrabalhos. Todo retrabalho custa tempo e dinheiro, invista um pouco mais no correto planejamento de cada atividade.

Eu não tenho autonomia sobre os recursos, e as tarefas não estão sendo cumpridas

Esta talvez seja a situação mais crítica e complexa de se resolver. Como comentei, a grande maioria das empresas possui uma organização funcional, baseada em departamentos. Sendo assim, você certamente precisará investir um bocado de tempo e esforço para obter os recursos necessários junto aos times operacionais. É possível manter uma boa relação com esses grupos, desde que você também observe regras de etiqueta básicas:

Compartilhe o plano de trabalho: ao solicitar recursos a um time funcional, compartilhe, caso não tenha feito antes, os objetivos da tarefa e o prazo necessário para que ela seja concluída. Se o prazo for inviável, o recurso não se comprometerá com o resultado
Respeite os acordos firmados: se o recurso foi disponibilizado por um tempo determinado, respeite este período e "devolva" o recurso para suas atividades rotineiras quando o prazo acabar. Negocie antecipadamente qualquer extensão neste prazo.
Compartilhe as conquistas com o time que cedeu o recurso para o projeto: demonstre apreço e reconheça o esforço extra que os times funcionais desempenham para cumprir com a entrega do projeto, este não é o trabalho oficial deles, portanto, reconhecimento e elogios formais são importantes aliados.

O projeto é mais complexo do que inicialmente planejado

Esta falha é difícil de aceitar quando a notícia é dada tarde demais. Como GP você precisa estar atento às mudanças de escopo e ao refinamento do plano do projeto, e compartilhar essas informações tão logo as tenha reconhecido. Antecipação é a chave, ninguém gosta de ser pego de "calças curtas".

Antecipe problemas: tão logo identifique riscos de atraso, aumento de custo, mudança de escopo, ou outros impactos para o projeto, certifique-se de entender as causas e as opções de contorno, mapeie os impactos e reporte-os adequadamente, em uma lista de riscos controlada.
Tenha sempre um plano de ação: lembre-se: seu sponsor não quer saber dos problemas, mas sim do que foi ou está sendo feito para solucioná-los. Apresentar um risco sem plano de mitigação é o mesmo que dizer: "o gato subiu no telhado".
Replaneje: sempre que possível, procure fazer alguns exercícios de planejamento das atividades futuras. Tempo perdido no passado somente pode ser recuperado com melhor performance no futuro. Quanto enfrentar um atraso no cronograma, apresente-o juntamente com as alternativas possíveis de compressão das atividades futuras, tentando minimizar o impacto para o projeto. Isso demonstra que você explorou as alternativas antes de simplesmente assumir um atraso na entrega.

Depois de tudo isso, tenha sempre em mente o seguinte: Não somos super-homens.

Todos somos feitos de carne, ossos e de sentimentos. Ficar angustiado ao fazer uma reunião de status report ou outra apresentação sobre os resultados/andamento do projeto raramente fará com que as coisas se desenrolem melhor, muito pelo contrário. Procure manter-se calmo e raciocinar antes de agir.

A vida de um gerente de projetos não é a mais tranquila do mundo, mas ela pode ser muito melhor com algumas precauções e atitudes assertivas da nossa parte.

Saúde e sucesso.

As certificações e o mercado de trabalho

2012-05-06T20:35:00.001-03:00

Olá pessoal, tudo bem?

Vou começar este post com uma pergunta direta: Você acredita nas certificações profissionais?

Se a sua resposta foi sim, você está entre a grande maioria das pessoas que aprova a realização de exames de certificação como uma forma de comprovação das habilidades adquiridas por um profissional.

No entanto, toda vez que se discute o assunto “certificação” uma sensação vem à tona: “O fulano vai lá, estuda através de simulados “testkings” da vida e passa na prova mesmo sem saber do que ela se trata...”

Isso me faz pensar que existem dois tipos de pessoas que se aventuram no mundo das certificações. O primeiro tipo é o do easy way of life, que chamarei carinhosamente de grupo TestKing, composto por aqueles que simplesmente pegam o simulado “de grátis” na internet, decoram e fazem a prova. Já o segundo tipo (espero que seja a maioria) vai pelo caminho das pedras – começam pelo estudo (em sala de aula ou independente), fazem os simulados, para depois comprovarem seus conhecimentos no exame de certificação.

Penso que a prática adotada pelo primeiro grupo, de fato tira um pouco do brilho das certificações, e, infelizmente, não há como negar que a prática é considerada comum no meio da TI.

Porém, eu procuro entender as certificações de um modo mais abrangente. Se uma pessoa se dedicou a estudar um tema específico a ponto de conseguir responder 50, 60 questões de forma correta em um exame de certificação, isso certamente demonstra que pelo menos essa pessoa possui duas qualidades: a primeira é a capacidade de aprendizado, pois, para ser aprovado no exame, este indivíduo preciso ao menos decorar as questões. A segunda é o interesse pelo tema, porque esta pessoa abriu mão de passar algumas horas no seu Playstation para ler e fazer os simulados para poder fazer a prova. Sendo assim, mesmo aqueles que optam por testking ainda obtém vantagens com a certificação.

Já o segundo grupo é composto por aqueles que acreditam na boa fé das pessoas e seguem o ritual da certificação – cursos, estudo, testes, labs e, por fim, a prova. Essas pessoas tem um diferencial ainda maior em relação aos membros do primeiro grupo: elas realmente conhecem o tema e sabem sobre o que estão falando. Fazem questão de montar laboratórios para testar o que estão estudando, visando não apenas a certificação, mas sim aquilo que é mais importante para a vida prática – o conhecimento.

Agora vamos para o lado prático da coisa: Imagine que você esteja contratando alguém e precisa optar entre duas pessoas em uma vaga de emprego, ambas com a mesma formação e qualificadas para a vaga, porém, uma delas com 2 certificações na área e a outra sem nenhuma. Qual das duas você escolheria? Eu não pensaria duas vezes antes de escolher aquela que apresentou as certificações...

Mas como saber se um candidato é do grupo testking ou não? Isso, meu amigo, só o tempo dirá. Os testkingers tendem a sofrer no dia-a-dia, pois os problemas reais nem sempre aparecem na prova... E nem sempre existe uma resposta pronta para ele no Google. Por isso, avalie todo o contexto, não apenas as certificações.

Em resumo: para mim, quem tirou a certificação demonstrou mais interesse pelo assunto, foi atrás, descobriu como fazer a prova, estudou (ainda que por testking) e passou na prova. Isso é suficiente para reconhecer que se trata de um profissional diferente da maioria. Não porque é mais inteligente, mas porque é mais interessado.

Em um tempo onde a informação é gratuita, o que diferencia uma pessoa da outra é a capacidade de transformar essa informação em conhecimento, e por consequência, o conhecimento em resultados.

Em resumo: O processo é falho? Sim, certamente... Mas ele não é inválido!

Para os candidatos uma dica: lembre-se que os contratantes estão avaliando uma série de informações no seu perfil – entre elas o seu interesse pelo assunto, traduzindo, certificações...

Por isso, se estiver em dúvida se deve ou não fazer determinado curso ou certificação, eu aconselharia: Faça todas que puder, sempre considerando o seu objetivo profissional. Fazer diversas certificações em áreas muito distintas (como por exemplo misturar certificações de infra e de desenvolvimento) podem dar a entender que o profissional não sabe bem qual carreira quer seguir, isso pode ser prejudicial. Escolha a carreira, depois se especialize! Mas faça do jeito certo: Opte pelo conhecimento, não pelo testking!

Saúde e sucesso!

Rodrigo Ramos, PMP

A empregabilidade do Gerente de Projetos

2012-04-12T22:16:00.000-03:00

Olá pessoal, tudo bem?
No meu último post prometi falar um pouco sobre a empregabilidade do gerente de projetos. Não consegui retornar a este tema até hoje, pois estava iniciando uma nova jornada, em uma nova empresa. Este post é um complemento de um post antigo sobre a característica temporária deste profissional. (Link para este post: http://mundopmp.blogspot.com.br/2011/11/o-gerente-de-projetos-um-profissional.html).

Não pretendo fazer um tratado sobre empregabilidade, apenas relatar fatos que ocorreram comigo nos últimos anos, além de alguns relatos de colegas de profissão.

Quando decidi dar um rumo diferente para a minha carreira, deixando de ser um engenheiro para me tornar gerente de projetos, fiz o que todos deveriam fazer antes de escolher uma profissão. Eu estava escolhendo a minha pela segunda vez, então pensei em uma estratégia para isso: classificados! A minha estratégia consistiu em analisar o que eu poderia oferecer com a minha formação e experiência profissional, e com isso avaliei quais eram as profissões nas quais meu perfil se enquadrava, e, de posse disso, passei a estudar anúncios da seção de empregos dos jornais e sites especializados. Logo percebi que havia uma ligação forte entre o meu histórico profissional e a função de gerente de projetos, e o melhor, o mercado estava precisando (e muito!) deste tipo de profissional.

Isso aconteceu há quase 8 anos atrás. Muita coisa mudou. A profissão ganhou reconhecimento e os profissionais passaram a ser assediados pelas empresas, pois estas logo perceberam que ter um profissional especialista na gestão de projetos poderia aumentar significativamente a chance de sucesso nas suas empreitadas.

E com isso o mercado mudou. Hoje em algumas áreas como TI, Engenharia, Automação de processos, Telecom, Civil entre outras, não se executa um projeto sem que haja ao menos um profissional em gestão de projetos. Isso faz com que a mobilidade desses profissionais seja enorme, trazendo consigo uma certa "guerra mercadológica" pelos melhores profissionais, mas é claro que sempre sobram vagas para aqueles que estão começando a carreira!

Se você está pensando em entrar nessa, reforço uma dica antiga: certificações são muito importantes, mas elas não garantem seu ingresso nesse mercado. Ter experiência técnica é um grande diferencial para poder começar nesta área sem grandes sustos. Cursos de especialização na área também são importantes. E é claro, acumule experiência. Só ela trará o conjunto de habilidades necessárias para ser bem sucedido nessa carreira.

Se você já está nessa há algum tempo, aproveite a boa fase que estamos vivendo e vá à luta! Existem muitas vagas esperando por profissionais preparados e dispostos a encarar a luta diária da carreira de gestão de projetos!

Saúde e sucesso!

Rodrigo Ramos, PMP

Metodologias ágeis - segunda parte

2012-01-27T23:07:00.000-02:00

Olá pessoal, tudo bem?

Algumas mudanças aconteceram na minha vida profissional nos últimos dias, dias corridos e cheios de surpresas, a grande maioria boas surpresas. Vou dedicar uma postagem para falar exclusivamente da empregabilidade do gerente de projetos, mas esse é um outro assunto...

Voltando à ativa no blog, gostaria de retomar as questões que discuti no meu penúltimo post, quando comecei a falar sobre metodologias ágeis e sua origem nos projetos de criação de produtos.
Naquele post fiz menção de que a metodologia PMI não era adequada a projetos de desenvolvimento de produtos, devido ao alto grau de incertezas presentes nesse tipo de projeto, este post é para defender esse ponto de vista, sem querer ser o dono da verdade, mas fazendo uma análise crítica sobre os prós e contras para que vocês possam tirar suas próprias conclusões.

Em ambientes de projeto convencionais, baseados no PMI, o termo requisição de mudança ou change request normalmente causa arrepios em muitos stakeholders. Mudanças normalmente não são benvindas em projetos. Mudanças (em geral) não são benvindas em nossas vidas. Somos moldados para resistir à mudança pelos nossos costumes, hábitos, crenças, etc, etc, etc... sem nos lembrarmos que foi a mudança que deu origem à raça humana....

Pois bem, depois da divagação, vamos voltar ao ambiente de projeto. Imagine que você está gerenciando um projeto e tudo está caminhando bem, os prazos estão sendo cumpridos, o orçamento, apesar de apertado, vai cobrir todo o restante do trabalho e o status de completude está em 95%. Você e a equipe já estão em ritmo de festa, planejando o que irão fazer no próximo fim de semana, coisa e tal, quando um gerente do negócio entra na sala (claro que isso sempre acontece às sextas-feiras às 17 e alguma coisa...) e diz aquilo que todos não querem escutar: "Pessoal, acabamos de sair de uma reunião, e a diretoria precisa mudar um pouco o projeto..." Não preciso dizer qual seria a cara de quase todos os membros da equipe, que dirá a do gerente do projeto. O pensamento "poxa, logo agora que a gente ia terminar esse projeto???" quase sempre vem à cabeça de todos...

Sob a ótica do PMI serão mais horas e horas de replanejamento, retrabalho, documentos, procedimentos e tudo o mais que normalmente é exigido para controlar uma mudança. O ímpeto humano de resistir aparece forte como o incrível Hulk e a reação é quase sempre a de dizer "ah, isso não dá pra fazer"...

Quantos de vocês já não tiveram vontade ou fizeram isso nessas situações? Acredito que muitos...

Mas porque somos tão avessos à mudanças? Por que ninguém gosta de trabalhar com incertezas... A incerteza gera insegurança, e isso mina as resistências de qualquer um. Outra coisa é que as mudanças normalmente não são acompanhadas de um aumento de prazo, ou de mais verba para o projeto. Tem que mudar e pronto!

A visão sobre as mudanças instituída pelos métodos ágeis é de que elas são inevitáveis, e muitas vezes são benéficas ao produto que o projeto está produzindo (principalmente em projetos com alto grau de incerteza), sendo assim, lutar contra as mudanças é inútil, pois elas SEMPRE ocorrerão. Então vamos encara-las como parte do projeto, e vamos trata-las adequadamente para que elas sejam encaixadas no plano.

A vantagem do método ágil para o tradicional neste quesito é que, como a mudança é esperada, a equipe não fica surpresa com isso (e nem o GP), e existe um fluxo pré-combinado com os stakeholders, onde as mudanças são avaliadas, mensuradas e então implementadas em prazo exequível. Tudo numa boa... E como o produto vai sendo desenhado de forma progressiva, e entregue em pacotes funcionais, as mudanças normalmente não são tão impactantes para o projeto como um todo, pois o que foi entregue e aceito está pronto, desse modo a mudança não impactará nos itens já entregues.

Parece sonho? Mágica? É... na prática as coisas nem sempre são assim... Mas mudar a atitude diante de uma mudança não planejada já é o primeiro passo para parar de sofrer com ela... Pense nisso!

Saúde e sucesso!

O Gerente de Projetos - Um profissional temporário

2011-11-28T21:17:00.000-02:00

Olá pessoal.

Já faz algum tempo que não publico nada aqui neste blog. Ultimamente o meu acesso à internet estava um tanto quanto escasso, e a vontade de ficar navegando após o dia inteiro de trabalho era muito pequena. Minhas sinceras desculpas.

Alguns fatos que ocorreram ultimamente me motivaram a publicar esta postagem - com um tema um tanto polêmico - sobre a condição temporária da maioria dos gerentes de projetos profissionais.

Vejamos bem: Os projetos - nossa área de atuação - tem uma característica fundamental, muito bem descrita pelo PMBOK: tratam-se de empreendimentos temporários, com começo e fim determinados. Mas o que dizer dos profissionais que se dedicam ao gerenciamento desses empreendimentos? Pois é... uma grande parte deles também tem "prazo de validade".

Não entendam esse post como uma reclamação, muito menos como uma lamentação. Trata-se de um alerta àqueles que pensam ingressar nesta área. Perdoem-me a franqueza e frieza, mas os profissionais de projetos tem uma "usabilidade" determinada, sendo que, ao fim do projeto, seu trabalho costuma não mais ser necessário (salvo alguns poucos que se dedicam prioritariamente à execução de projetos em fábricas de software ou em empresas dedicadas especificamente à venda de projetos).

Para aqueles que dão a sorte de tomar parte em projetos de verdade - aqueles com P maiúsculo, inéditos de fato, com prazos, metas e objetivos definidos - devem ter em mente que o seu trabalho também acaba ao término do projeto... Caso você pretenda entrar nessa área, tenha isso em mente: o seu trabalho é temporário!

Mas então como lidar com essa característica na sua vida profissional? Ora, você planeja muito bem os projetos dos seus contratantes, não é mesmo? Então planeje muito bem o seu projeto de vida, para não ser pego de surpresa por essa situação. Fatos previsíveis não podem ser considerados supresas - lembre-se da gestão de riscos e aplique-a à sua vida!

No meu caso, já atuo com projetos há mais de 10 anos, portanto, já me adaptei a essa "vida nômade" que levamos, sendo assim dedico uma parcela daquilo que ganho para os intervalos entre os projetos. Para ser sincero, me adaptei tão bem que às vezes eu cobro de mim mesmo mudanças de ares quando não vejo mais perspectivas reais para o desenvolvimento pessoal e profissional.

Então, sendo bem direto: se você não quer prazo de validade para sua vida profissional, pense duas vezes antes de investir seu tempo e dinheiro em uma formação em gerenciamento de projetos...

Agora, se você está buscando uma vida menos acomodada, com oportunidades de crescimento a cada nova experiência, aumento da sua rede de contatos (a real, não aquela da internet!), então você está no caminho certo! E, como não há bem que sempre dure, e não há mal que nunca acabe, saiba tirar o melhor de cada oportunidade que a vida te der. Programe-se para os períodos de vacas magras e viva intensamente todas as suas experiências profissionais, sejam elas permanentes ou temporárias.

E não se deixe abater caso perceba que seu trabalho terminou. Isso é um dos sinais de que seu trabalho foi bem feito! Tenha isso em mente, levante a cabeça, perceba que você cumpriu com aquilo com o que se comprometeu - e isso é o maior sinal do seu sucesso!

Um grande abraço, em especial para os valentes profissionais que se dedicam para elevar o gerenciamento de projetos ao título de profissão.

Saúde e sucesso,

Rodrigo Ramos, PMP

Agile Project Management - Funciona para você?

2011-09-23T12:00:00.000-03:00

Bom dia pessoal, tudo bem?

Já faz algum tempo que me interesso bastante pelo tema dos métodos ágeis para gerenciamento de projetos e como elas podem agregar valor ao projeto e principalmente ao moral do time. Não há como negar que algumas vezes a burocracia que metodologias mais conservadoras impõe sobre o trabalho do projeto acabam por causar problemas no logo prazo dentro da equipe, como a insatisfação, falta de motivação e às vezes um sentimento de frustração.

Para quem vive o mundo do PMI, quando lemos o Manifesto Ágil, sentimentos antagônicos de encantamento e de estranheza sempre aparecem. Mas os pontos relevantes (que aqui colocarei em uma tradução livre) do manifesto causam tanto impacto que não podemos deixar de levá-lo em consideração. Neste manifesto os pontos de destaque (na minha modesta opinião) são:

As pessoas e as interações entre elas são mais importantes que os processos e ferramentas
Produto funcionando é mais importante que documentação abrangente
Colaboração com o cliente é mais importante que negociação de contratos
Responder às mudanças é mais importante que seguir o plano

Para muitos praticantes do que chamo PMI'ismo, essas coisas podem chegar a causar arrepios, afinal, o PMBOK é fundamentado em processos bem definidos, tem passagens importantes sobre o controle de mudanças, negociação de contratos, enfim, é um antagonismo que pode causar desconforto naqueles mais ortodoxos.

Porém alguns fatos importantes devem ser considerados ao analisarmos ambientes de projetos específicos, em especial projetos de desenvolvimento de novos produtos, que inicialmente adotou o PMBOK como padrão para a gestão de projetos. Nessa área, um fato começou a se tornar visível: o índice de sucesso e satisfação dos clientes sempre estava abaixo da expectativa.

Ora, se estamos desenvolvendo um produto, algumas caraterísticas devem ser observadas:

O produto deve se adequar a novos requisitos que aparecem durante o processo de desenvolvimento
As mudanças no produto podem significar maior índice de sucesso deste produto depois do projeto concluído
O cliente (que é o dono do produto) deveria participar ativamente das decisões do projeto, e alterá-lo de acordo com o seu plano de negócios
O plano de negócios também pode mudar no decorrer do projeto
O cliente sempre quer ver alguma coisa pronta nas reuniões de status
A equipe quer trabalhar em paz durante o processo de criação do produto

Em resumo: o processo de desenvolvimento de produtos não combina muito com o método do PMI (voltarei a este assunto no próximo post). Era necessário alguma coisa nova, que quebrasse o paradigma da rigidez ditada pelo PMBOK. Nasceram então as metodologias ágeis de gerenciamento de projetos.

Hoje em dia todos pensam que isso só se aplica a desenvolvimento de software, mas os "ratos da informática" estão enganados. O método ágil surgiu (pasmem) na indústria automobilística, no processo de desenvolvimento de novos modelos de carros. Mais tarde foi adaptado e amplamente adotado pela indústria de desenvolvimento de software, onde o Scrum emergiu.

Os princípios são básicos e muito simples: rodadas de planejamento e rodadas de execução do plano, nada muito diferente do modelo tradicional. A diferença está na maneira como isso é realizado. O PMI e seu método nasceram em um momento onde os "chefes" e "gerentes" tinham formação técnica, e conheciam muito mais do que seus subordinados. Por isso o GP era o centro de tudo. Todas as decisões, todas as medidas eram tomadas por ele. Claro que ele ouvia sua equipe, mas a decisão final era do GP.

Hoje, com o alto grau de especialização dos trabalhadores, muitas vezes o "gerente" não é mais o grande técnico do passado. Normalmente seus subordinados conhecem a tecnologia em um nível muito maior do que ele. Pensando nisso, alguns visionários resolveram "derreter" a função do gerente do projeto, dando maior liberdade para a equipe do projeto (que deve ser multidisciplinar) se auto-organizar.

Após algumas experiências, percebeu-se que o moral da equipe estava mais elevado, as entregas do projeto haviam sido realizadas em prazo menor e com menor esforço. Estavam criados os fundamentos do APM (Agile Project Management).

Alguns devem estar se perguntando: e onde foi parar o gerente do projeto?

Bem, essa resposta não é simples, uma vez que a orientação dos métodos ágeis é mais aderente à gestão de produtos, e não de projetos, a função do GP foi dividida em 3 partes:

Macro gestão - Atribuída ao "dono do produto"
Micro gestão - Atribuída ao time de desenvolvimento
Processos - Atribuída ao que poderia ser chamado de GP

O "GP" nesses casos é o líder servidor ou colaborativo. Ele trabalha para que a equipe não tenha nenhum tipo de impedimento durante o desenvolvimento do produto. O "GP PMI" também exerce esse papel, porém quando somos ágeis, a equipe é responsável por resolver seus próprios problemas, excluindo do GP a função de gestão micro de RH (conflitos, etc.). Isso passa a ser responsabilidade da equipe, assim como o planejamento de cada ciclo de desenvolvimento e a resolução de problemas técnicos do projeto.

Então o que o GP faz? Ele remove os impedimentos. Um impedimento é algo que está além da capacidade de resolução da equipe, como por exemplo falta de um treinamento específico, algum recurso material necessário para o projeto e coisas desse tipo. O GP também é o responsável por proteger a equipe das influências externas, pois, durante um ciclo de desenvolvimento, a equipe deve estar focada exclusivamente na resolução dos problemas do projeto.

Confuso? Eu também achava... Assustado? Eu também fiquei... Isso é a morte dos PMP's? Certamente não.

Os métodos ágeis funcionam muito bem quando não se tem um escopo claro e definido, quando iterações no plano são desejadas e esperadas, quando o time-to-market de um produto precisa ser reduzido (ainda que ele seja apresentado com menos funcionalidades do que o produto final). Para aqueles projetos onde o escopo é claro, o prazo e o custo são definidos, o modelo PMI ainda se aplica de forma mais eficaz. Imaginem um prédio ser planejado e construído em etapas independentes? Provavelmente não seria o método mais eficiente e eficaz para fazer isso...

O que não podemos é virar as costas para o movimento ágil, pois ele preenche lacunas expressivas que o PMBOK não sabe como tratar. Até mesmo a integração dos métodos ágil e tradicional é possível, e até mesmo saudável!

O que nós, gerentes de projetos e agentes de mudanças, precisamos ter claro em nossas mentes é que toda metodologia, todo framework, todas as boas práticas são adaptáveis e devem ser adaptadas à nossa realidade. Por isso eu indico sempre o estudo. Estude sempre. Leve consigo o que considerar adequado, guarde para o futuro aquilo que não considera ideal hoje e esteja pronto para quebrar os seus próprios paradigmas na sua profissão. Você não é gerente de projetos, você está gerente de projetos. Aproveite a jornada!

Um grande abraço!

Saúde e sucesso,
Rodrigo Ramos, PMP, CSM

PMI lança nova certificação em metodologia ágil: PMI-ACP

2011-08-23T11:40:00.000-03:00

Olá pessoal, tudo bem?

Tenho certeza que muitos dos leitores deste blog já ouviram falar em metodologias ágeis para o gerenciamento de projetos. Muitos têm sentido o crescimento de demanda do mercado por profissionais capazes de colocar em prática o potencial das metodologias ágeis.

As empresas que adotaram metodologias ágeis tem registrado o valor agregado por esta prática:

Feedback do cliente: como o cliente está envolvido no desenvolvimento do projeto, existe uma tendência de que o resultado do projeto esteja mais alinhado com sua expectativa, reduzindo retrabalhos;
A maior visibilidade e influência sobre o progresso do projeto possibilita corrigir desvios mais cedo;
Medições e retornos facilitados: a maior visibilidade sobre o escopo e sobre os prazos dos entregáveis possibilita um retorno de investimento sobre o projeto mais rápido.

Existem diversas iniciativas no campo das metodologias ágeis, e a mais bem sucedida até o momento é o SCRUM. Obviamente o PMI não quer ficar de fora da festa, então lançou o seu próprio programa de certificação em metodologias ágeis, o PMI-ACP, ou Agile Certified Practitioner.

Esta decisão do PMI se baseou no resultado de uma pesquisa (Pulse of the Professional), que demonstrou que a adoção de práticas padronizadas para a gestão de projetos resultam em melhor performance na execução dos projetos.

Uma das práticas monitoradas nos últimos anos pelo PMI é o contínuo crescimento das metodologias ágeis, notando que muitos profissionais de gerenciamento de projetos apontavam esta prática como seu "canivete suíço" da sua "caixa de ferramentas".

Como resultado, muitos PMOs têm solicitado aos seus GPs que apliquem métodos ágeis nos seus projetos.

Segundo a pesquisa, 68% das organizações entrevistadas que utilização métodos ágeis revelaram que uma certificação ágil traria valor para os profissionais e para a organização. Outro dado relevante foi o fato de que 63% dos empregadores considerarem e apoiarem seus colaboradores a possuir uma certificação ágil.

Os requisitos para a prova são parecidos com os da certificação PMP:

Diploma de 2º grau;
2000 horas de experiência em projetos comprovadas nos últimos 5 anos;
1500 horas de experiência em metodologias ágeis, apuradas nos últimos 2 anos;
21 horas de treinamento em metodologias ágeis

Os custos divulgados pelo PMI também são expressivos:

Para membros do PMI: USD 435,00
Para não-membros: USD 495,00

O exame consiste de uma prova realizada em computador, composta de 120 questões, das quais as 20 primeiras serão utilizadas como pré-teste, e não contam para o resultado do exame. O exame tem a duração de 3 horas.

Ainda segundo o PMI, o conteúdo da prova se baseia em:

Ferramentas e técnicas ágeis: 50%
Habilidades e conhecimentos em metodologias ágeis: 50%

Estamos notando que o crescimento e a adoção de metodologias ágeis é um processo irreversível. O PMI não quer ficar de fora dessa onda e tratou de preparar uma certificação neste contexto.

O processo ainda está em fase experimental, sendo que as primeiras provas devem ser realizadas a partir deste mês (agosto/11) .

É mais uma opção para rechear o currículo, e, em conjunto com a certificação CSM (Certified Scrum Master), uma forma de demonstrar proficiência nesta prática que tem cada vez mais adeptos.

Saúde e sucesso!

Rodrigo Ramos, PMP

Como implantar uma metodologia para gerenciamento de projetos na minha empresa?

2011-07-13T18:10:00.001-03:00

Olá pessoal, tudo bem?

Gostaria de, neste post, comentar sobre as adaptações que as empresas fazem em relação aos processos descritos no PMBOK e como essas alterações podem ser utilizadas para moldar o gerenciamento de projetos para um modelo adequado à sua empresa.

O primeiro passo que precisamos dar é entender o quê o cliente espera ganhar com o gerenciamento de projetos, para podermos criar uma linha de trabalho que tenha como objetivo atender às expectativas deste cliente.
O caso onde atuei possuía alguns requisitos bem definidos:

A alta gerência e diretoria comercial queriam ter visibilidade do status dos projetos em andamento, em planejamento e encerrados;
Necessidade de melhorar a definição e o controle do escopo dos projetos, pois quase sempre havia desvios nas entregas não mapeados, gerando retrabalhos;
Desejo de criar um padrão para a entrega de documentação dos projetos;
Criar um ambiente de colaboração para as equipes do projeto;
Dar visibilidade de todo o processo de gerenciamento do projeto através de indicadores de fácil compreensão.

Este conjunto de requisitos é complementado por um conjunto de variáveis ambientais, tais como:

A equipe de projetos não controla o custo real dos projetos, apenas as horas trabalhadas.
A equipe de projetos não realiza compras diretamente, apenas as requisita para o departamento de compras;
Os projetos na sua maioria são muito semelhantes em escopo
Os projetos são em sua grande maioria de curto prazo (< 2 semanas)
A documentação dos projetos possui um conjunto restrito de documentos.

Estas diretrizes nos dão algumas pistas de como devemos adaptar os processos do PMBOK (que foram escritos baseados em projetos para levar o homem à Lua, mas podem não ser adequados para pequenos projetos...) para que eles funcionem no mundo real da sua empresa. Por exemplo: Uma vez que a equipe de projetos não controla os custos reais do projeto, seria necessário um grande processo de gerenciamento de custos?

Adaptar significa, muitas vezes, remover alguns processos do PMBOK do âmbito de gerenciamento de projetos da empresa, de modo a simplificar a implantação de uma metodologia que crie um padrão de entrega, pois quanto mais processos gerenciados existem, maior é o custo e o tempo gasto pelos gerentes e analistas de projetos nessas atividades.

Outro passo importante para aumentar as chances de uma nova metodologia ser bem sucedida, é observar a aderência a processos já seguidos, ainda que informalmente, pela empresa. Para isso, é necessário observar como a empresa funciona HOJE. Esta etapa, no meu ponto de vista é a mais importante do processo de implantação. Com base no que se faz hoje será definido como a empresa poderá funcionar amanhã.

Esta fase por vezes é "esquecida" durante um projeto de implantação de uma nova metodologia. Algumas consultorias possuem um "kit padrão" que acreditam funcionar (com o mínimo de adaptações) para qualquer cliente. Nem sempre é assim que a coisa acontece na prática...

Muitas vezes as empresas já possuem um processo informal em vigor, os colaboradores sabem o que fazer e como fazer, porém, por não haver um padrão estabelecido, cada um executa as atividades ao seu modo. O resultado: falta de padrão, sensação de desorganização e de falta de preparo da equipe.

O mapeamento dessas atividades pode ser muito útil para a criação de uma metodologia que de fato funciona para aquela empresa, e isso certamente irá diminuir a resistência à sua adoção pelos colaboradores, uma vez que as suas atividades diárias serão menos impactadas do que se tentássemos uma implementação "do zero".

Voltando ao caso que originou este post: a metodologia do cliente em questão reduziu de 42 processos definidos no PMBOK para apenas 14, observando sempre todos os sistemas existentes na empresa, fontes de dados e padrões de documentação. Desses 14 processos, cerca de 10 já eram executados pela equipe do cliente, ainda que nem eles mesmos soubessem. Coube ao projeto de implantação da metodologia o trabalho de documentar as rotinas e procedimentos de forma a padronizar o trabalho dos analistas, bem como as saídas de cada processo.

O próximo passo é realizar avaliações constantes no processo, além de medir o desempenho atual contra o que se realizava no passado, para buscar melhorias e aumento na performance dos projetos. Tenham certeza que voltarei com os resultados, assim que os tiver disponíveis, para compartilhar com vocês.

A adoção de uma metodologia própria traz inúmeras vantagens para o processo de implantação, porém, cria a necessidade de uma manutenção mais constante, muitas vezes sendo necessária a criação de um PMO, ainda que simples, para "tomar conta" do processo e identificar e corrigir os desvios.

A lição que eu tirei deste projeto é que, independente do tamanho e do grau de maturidade de uma empresa, ela sempre poderá se beneficiar de uma metodologia para gerir seus projetos. E o caminho para o sucesso ao implementar uma metodologia pode ser retirado da sabedoria popular: nem tanto ao mar nem tanto à terra.

E uma dica: É mais fácil adaptar a metodologia ao funcionamento da empresa do que a empresa à metodologia.

Saúde e sucesso!

Rodrigo Ramos, PMP

PMI: Reportando PDUs – Mantenha sua certificação PMP!

2011-06-15T14:51:00.000-03:00

Você estudou, treinou, ralou e finalmente conseguiu se tornar um PMP. Parabéns pelo seu esforço e pela dedicação que realmente foram necessários para esta conquista!

Ao contrário de muitas certificações de mercado, onde basta passar na prova para estar certificado pelo resto da vida, o PMI exige que os profissionais que possuem suas certificações participem de um programa de reciclagem e aprimoramento profissional.

Para manter sua certificação é necessário cumprir um plano de desenvolvimento profissional, monitorado pelo PMI, através do report de PDUs, ou Professional Development Units. O processo de reporte de PDUs é feito pelo site do PMI (www.pmi.org).

Para garantir sua certificação o PMI exige que cada profissional certificado reporte ao menos 60 PDUs durante o período de 3 anos o qual a certificação é válida.

O processo foi atualizado em 1º de Março de 2011, de modo a simplificar a vida dos certificados. Entre as mudanças que ocorreram podemos destacar:

•    A estrutura de classificação das PDUs foi reduzida de 18 categorias para apenas 6;
•    Todas as categorias obedecem a regra de 1 hora de estudo = 1 PDU;
•    As categorias foram expandidas para abrigar os avanços da WEB 2.0 (Ambientes de colaboração);
•    Foram criados limites para determinadas categorias, obrigando os certificados a buscarem a educação continuada em gerenciamento de projetos para manterem sua credencial.

As categorias de PDUs são divididas basicamente em Educacional e Aprimoramento Profissional. Cada categoria possui 3 classes, conforme a tabela abaixo:

No novo padrão de reporte, as PDUs referentes ao Aprimoramento Profissional (D, E e F) foram limitadas a 45 PDUs por ciclo de 3 anos, sendo que a categoria F. possui limite de 15 PDUs.

A categoria C. Auto-estudo também possui limite de 30 PDUs por ciclo. As demais categorias educacionais não possuem limites de reporte.

Esta proposta visa manter os profissionais atualizados com as novidades da área de gerenciamento de projetos, sendo assim, estudar (em sala de aula) é obrigatório para manter-se certificado.

O processo de report no site do PMI é bastante simples. Ao clicar em Report PDUs, você será direcionado ao site específico para entrar com os dados referentes à sua solicitação de PDUs.

O processo é autoexplicativo, mas prepare-se: será necessário digitar um grande número de informações para cada reporte, tais como: nome do projeto, duração do projeto, áreas de conhecimento envolvidas, nome da instituição de ensino, datas de realização de cursos, duração de cursos, etc.

Abaixo segue a tabela extraída diretamente do site do PMI, onde constam os limites para cada categoria de PDUs disponível no site do PMI para acesso público.

Limites de PDUs por categoria

É importante ressaltar: A manutenção da sua certificação depende do reporte de PDUs. Se você não cumprir o estabelecido pelo PMI (60 PDUs a cada 3 anos), você perderá sua certificação. Não existe segunda chance nesse caso, se acontecer, todo o processo de certificação deverá ser iniciado novamente a partir do zero. É claro que ninguém quer que isso aconteça, por isso, com esse post espero ter ajudado a esclarecer algumas dúvidas sobre o processo de report de PDUs, e também sobre a manutenção da sua credencial PMP.

Saúde e sucesso!

Rodrigo Ramos, PMP

Gerente de projetos: Qual o perfil ideal: especialista ou generalista?

2011-05-03T18:11:00.000-03:00

Quantas vezes não nos deparamos com anúncios de vagas para GP que têm como requisitos para a candidatura alguma certificação ou conhecimento técnico no ramo de atuação da empresa que está contratando?

Confesso: dos muitos anúncios que li para criar esse post, TODOS eles pediam ao menos conhecimentos na área de atuação das empresas contratantes, além dos conhecimentos em gerenciamento de projetos.

Resolvi abordar o tema da especialização no campo de gerenciamento de projetos por alguns motivos, entre eles o fato de estar atuando em TI hoje em dia, apesar da minha formação acadêmica ser na área de engenharia elétrica.

Comecei a me envolver com gerenciamento de projetos ainda na engenharia, mais especificamente em automação de processos. No entanto, a vida de viagens me impedia de voltar à sala de aula e fazer uma especialização ou uma pós-graduação. Sabia que esse caminho cobraria seu preço mais para frente na minha carreira e por isso resolvi trocar a automação pela TI, sempre dentro do escopo do gerenciamento de projetos.

Inicialmente pensava que um gerente de projetos não precisaria obrigatoriamente ter grande vivência na área de atuação do seu projeto, afinal, ele tinha que ser especialista em gerenciamento de projetos, não nas disciplinas técnicas relacionadas ao produto.

Armei-me de coragem e fui tentar a sorte na TI. Obviamente, aquilo não era totalmente desconhecido para mim, afinal, nos meus projetos de engenheiro a maior parte do tempo tratava de assuntos referentes a desenvolvimento de aplicações e configuração de servidores.

Sofri com a discriminação de empresas que queriam um gerente de projetos vindo da área técnica, que conhecessem a fundo linguagens de programação entre outras coisas. Cheguei até a criticar o pessoal do RH dessas empresas, por não acreditar que esta fosse a melhor opção para um GP. Por fim acabei entrando na área que tinha mais afinidade com a engenharia, os projetos de infraestrutura e Datacenter.

Com o tempo, percebi que o grau de informação e conhecimento técnico que estava sendo requisitado pelo trabalho de GP na TI era muito maior do que eu esperava, e isso me surpreendeu… Nesse mundo, se o GP não tiver conhecimento, ao menos mediano, em infraestrutura, alguma coisa de banco de dados e desenvolvimento, sua vida será, no mínimo, desgastante. Solução que eu encontrei? Estudar e melhorar meu conhecimento técnico, não em GP, mas em TI…

Hoje, depois de cerca de 4 anos na área, percebo que o investimento de tempo e dinheiro nesse estudo valeu a pena. Não sou especialista, mas também não sou leigo! Isso é de fundamental importância ao discutir o planejamento de um novo projeto com a equipe, ao apresentar alternativas para contorno de problemas no projeto e para discutir abertamente os pontos de dúvidas.

Depois de muito pensar sobre isso, me pergunto novamente: que tipo de gerente de projetos o mercado procura? A resposta que eu acho mais interessante é: O mercado sempre procura super-heróis - porém nenhum de nós nasceu em Krypton…

E a solução que eu acho ser a melhor é:

Passo 1: Ser especialista no que você faz: GERENCIAMENTO DE PROJETOS

Lembre-se: esta é a sua profissão! E por si só, ela já conta com um volume de conhecimento enorme. Dedique-se a conhecê-lo por completo. Estude e desenvolva seu perfil profissional.

Passo 2: Seja generalista na sua área de atuação.

Hoje percebo que, se não impossível, é inviável gerenciar um projeto onde não se tem idéia do que será ou de como funciona o seu produto. Se você atua na construção civil e não é engenheiro civil, terá problemas… Se atua em estaleiros e não é engenheiro naval, terá problemas… Portanto, ter algum conhecimento técnico na sua área de atuação é um dos pontos críticos de sucesso da sua carreira.

Porém, atenção para não tentar “roubar a cena”. Nós, gerentes de projetos, somos coadjuvantes na produção do produto. Isso cabe aos especialistas de verdade - consultores, técnicos, etc. Se você atuava como uma liderança técnica de projetos e outros cargos afins antes de se tornar um GP, saiba que o seu lugar agora é outro. Nesse ponto ficamos nos bastidores. O ponto de equilíbrio, ao meu ver, é atingido quando se tem o conhecimento necessário para não ser pego de surpresa pelos clientes e se consegue conversar sobre assuntos técnicos sem muitos detalhes com os membros da equipe.

A conclusão que eu tirei pela experiência que vivi na área de informática é que, de fato, é muito importante possuir algum conhecimento técnico na área de atuação da empresa que você representa. Hoje olho para trás e vejo que aqueles analistas de RH que pediam conhecimento específicos da área (os quais eu cheguei a criticar) não estavam tão errados. De fato isso é realmente um diferencial, e um fator importante no sucesso dos projetos.

Mas além disso, é fundamental que você conheça a fundo as técnicas do gerenciamento de projetos, afinal, você normalmente terá uma equipe técnica para lidar com os assuntos referentes ao produto do projeto, mas quase nunca terá a quem recorrer para tratar os assuntos do gerenciamento deste projeto, portanto, se tiver que focar em uma das áreas, foque na Gestão de Projetos.

Sucesso e saúde,

Rodrigo Ramos, PMP

Gestão de riscos em projetos – Uma prática ainda pouco difundida…

2011-04-15T13:53:00.000-03:00

Após a sessão de explicações sobre como se tornar um profissional certificado PMP, começo uma sessão de discussão sobre alguns temas relevantes para o gerenciamento de projetos, que normalmente não são levados tão a sério quanto deveriam ser pela maioria dos GPs que tenho contato.

Um desses tópicos é a gestão de riscos de projetos.

A gestão de riscos de projetos é tão importante que alguns autores sobre o tema chegam a afirmar que gerenciar projetos se resume a gerenciar riscos. Esta visão, um tanto simplista, do processo de gerenciamento de projetos, demonstra a forte associação existente entre a criação de algo novo, inédito e sem referências passadas, ao risco associado a esta empreitada.

O guia PMBOK (2008) define risco como sendo “um evento ou uma condição incerta que, se ocorrer, tem efeito em pelo menos um objetivo do projeto”. A abordagem do PMI não denota risco como um evento necessariamente ruim, mas sim como um evento que gera impactos, negativos ou positivos, em algum objetivo do projeto.

Os componentes básicos do risco são:

Potencial de perdas e danos.
Incerteza de perdas e danos.
Relevância das perdas e danos.

O risco é uma característica comum a todos os projetos. Projetos são abstrações de um trabalho futuro, inovador e coberto por incertezas, sejam pelas suposições utilizadas para efeito de planejamento, sejam pelo ambiente onde o projeto será implementado ou por fatores externos, às vezes desconhecidos, aos quais o ambiente do projeto está associado.

Ainda que os riscos dos projetos não possam ser eliminados completamente, a aplicação de uma metodologia estruturada para identificação, análise, controle e resposta aos riscos contribui para que eventos não previstos inicialmente pela equipe do projeto possam ser tratados segundo uma ordem pré-estabelecida. Essa abordagem auxilia a equipe em todas as fases do processo de gerenciamento de riscos, contribuindo para que o projeto seja bem sucedido em seus objetivos.

Muitas das decisões que ocorrem no projeto acontecem por causa dos riscos. Por este motivo é necessário ter um bom controle dos riscos que podem acontecer e ter estratégias para lidar com eles.

Normalmente no dia a dia dos gerentes de projetos se resume ao PMI. De fato, o PMI traz uma abordagem bastante ampla ao gerenciamento de riscos, no entanto, o gerenciamento de riscos é muito mais antigo do que o próprio gerenciamento de projetos, e existem diversos frameworks que abordam essa questão além do PMBOK.

Podemos citar como exemplo a norma ISO/IEC 12207, que é a primeira norma internacional que descreve as atividades do ciclo de vida de um software, ou o modelo do CMMi, que visa à melhoria da maturidade dos processos de desenvolvimento de software.

Esses são apenas alguns exemplos, focados na área de desenvolvimento de aplicativos. Existem muitos outros modelos voltados para o mercado financeiro, seguros, investimentos em projetos e outros, que podem ser utilizados como base para criação de um padrão de gerenciamento de riscos para projetos.

O lado bom é que praticamente todos os frameworks compartilham uma estrutura de processos, e as semelhanças entre eles são muito maiores do que as diferenças. Essa estrutura se resume a alguns passos seqüenciais – 1. Planejamento, 2. Identificação, 3. Análise, 4. Tratamento e 5. Monitoração dos riscos. Se você estiver se lembrando do PMBOK nesse momento, não é fique surpreso. Os passos descritos aqui são os mesmos que o PMBOK descreve, afinal, o próprio PMBOK é uma compilação de práticas já reconhecidas.

Mas porque o gerenciamento de risco não é uma prática comum no gerenciamento de projetos?

Muitos GPs alegam que para poderem usar a gestão de riscos de forma adequada é necessário um histórico de projetos semelhantes, com o qual se possa obter uma lista de riscos detalhada, com todos os impactos que ocorreram no projeto entre outras informações.

Essa “desculpa” não deveria ser sequer cogitada. Qualquer estimativa, por pior que seja, sempre é melhor do que não ter nenhuma estimativa. E como podemos nos valer dessa desculpa, se queremos melhorar o histórico de projetos da organização? Vale a máxima, o que veio primeiro: o ovo ou a galinha?

Independente de qual framework você utilize, o importante é sempre se lembrar da importância dos riscos em um projeto. Não importa qual metodologia você considera a melhor, o que realmente importa é que o gerenciamento de riscos seja levado a sério, pois é o fator mais crítico de qualquer projeto, desde os mais simples até os mais complexos.

Saúde e sucesso!

Rodrigo Ramos, PMP

Passo a passo no site do PMI: Como me tornar um PMP?

2011-03-28T13:49:00.000-03:00

Olá pessoal, tudo bem?

Faz algum tempo que publiquei meu último artigo, estive ausente por motivos de trabalho, mas estou de volta com o tópico que prometi: a aplicação para a certificação PMP.

No último post eu comentei os pré-requisitos para se tornar elegível a realizar a prova. Neste post irei um pouco mais adiante, demonstrando como inserir as informações que você já deve ter levantado, se seguiu o post anterior, nos moldes do PMI.

Como havia comentado, a etapa mais trabalhosa do processo de aplicação é relacionar as experiências profissionais para cumprir com o pré-requisito de tempo de atuação e tempo de experiência.

1º PASSO: Criar um login no site do PMI

O primeiro passo é bastante simples, portanto não colocarei muitos detalhes.

Para criar o seu login basta acessar a página oficial do PMI (WWW.pmi.org) e clicar no link Login e depois em Register Now.

Siga os passos do site e pronto, você terá um login válido no PMI.

2º PASSO: Aplicar para a certificação PMP

O PMI possui uma série extensa de certificações, entre elas o PgMP, o CAPM e o PMP.

Clique sobre o link Apply for PMP Certification

Siga os passos do guia do site para inserir seus dados pessoais (endereço, e-mail, telefone, etc).

Após inserir seus dados pessoais, será necessário inserir seus dados referentes à educação. Nesta janela você deve inserir todos os dados obrigatórios pelo site para poder prosseguir com a aplicação. Não se preocupe se você não puder completar tudo de uma única vez – o site permite que você interrompa o processo de aplicação e volte a ele mais tarde para completar os itens que ficaram faltando.

A partir do próximo passo, você será solicitado a inserir as informações referentes à sua experiência profissional. No último post eu coloquei quais são os requisitos para se torna um PMP, vamos lembrar rapidamente quais são eles:

Para candidatos com formação completa em nível superior:

a. Mínimo de 3 (três) anos (ou 36 meses) de experiência profissional em gerenciamento de projetos;

b. Mínimo de 4500 horas dedicadas à liderança ou controle de atividades de projetos;

c. Mínimo de 35 horas de treinamento presencial em gerenciamento de projetos;

Para candidatos com 2º grau completo:

a. Mínimo de 5 (cinco) anos (ou 60 meses) de experiência profissional em gerenciamento de projetos;

b. Mínimo de 7500 horas dedicadas à liderança ou controle de atividades de projetos;

c. Mínimo de 35 horas de treinamento presencial em gerenciamento de projetos;

Na tela Step 1: Application |Experience Worksheet você deverá inserir, uma a uma, todas as suas experiência relacionadas à gestão de projetos.

O PMI solicita que essa informação seja detalhada no nível de fases do projeto, ou seja, para cada experiência adicionada, você deve detalhar em que fase do projeto ela foi adquirida (iniciação, planejamento, execução, controle e encerramento).

Além disso, deverá ser adicionado, para cada experiência documentada:

Dados da empresa que desenvolveu o projeto (nome, endereço, etc)
Seu cargo no projeto e na empresa
Datas de início e término do projeto
Nome do projeto
Segmento do projeto
O nome de contato na empresa que possa comprovar sua experiência nesse projeto
O número de horas de experiência em cada fase do projeto (detalhes mais adiante)

Uma dica valiosa que me ajudou bastante foi montar uma planilha contendo todas as informações necessárias para a aplicação, de modo que pudesse consultar e atualizar esses dados facilmente.

O reporte de horas em projetos é o ponto que mais dá trabalho para inserir. O PMI é bastante crítico nesse ponto, sendo um dos maiores motivos de auditoria no processo de certificação.

Para cada fase do projeto haverá uma lista de atividades (veja as figuras em anexo para ter a lista completa), onde você deverá inserir o número de horas gastas em cada uma dessas atividades:

Iniciação: 5 atividades
Planejamento: 6 atividades
Execução: 8 atividades
Controle e monitoração: 4 atividades
Encerramento: 7 atividades

O motivo de muitas pessoas serem surpreendidas em auditorias pelo PMI se deve ao fato de preencherem esta etapa do processo de forma incorreta ou até mesmo mentirosa. Lembremos de alguns pontos que devem ser considerados ao preencher as páginas de experiência:

Qual deve ser a divisão de trabalho comum em um projeto “normal”?
É comum gastar 80% do tempo do projeto na iniciação?
É comum reportar enorme conhecimento em encerramento sem ter participado de outras fases de um projeto?

Essas perguntas são feitas pelo PMI ao analisar sua aplicação para a prova. O PMI prega que a distribuição normal de esforço em um projeto é distribuída em:

Iniciação: 10-20%
Planejamento: 20-30%
Execução: 40-50%
Controle e monitoração: 20-30%
Encerramento: 10-20%

Se sua experiência estiver muito fora dessa estimativa só existe uma justificativa: sua função no projeto. Se você é um profissional de planejamento (planner) é normal investir mais tempo durante os processos de planejamento e controle. Se você é um analista desenvolvedor, é comum gastar mais de 80% do tempo na execução do projeto. O fato é: se as informações forem discrepantes, a probabilidade de cair na auditoria aumenta. Por isso lembre-se: tenha todas as informações e contatos sobre seu histórico às mãos, para qualquer eventualidade.

É bom lembrar também que o PMI poderá (sem avisar) contatar (por email ou telefone) as pessoas que você citar na sua aplicação como sendo os responsáveis pela confirmação das informações. Pela boa educação, avise essas pessoas de que isso poderá acontecer e informe a importância deste processo para a sua carreira profissional. Peça ajuda se preciso.

E a dica mais importante, que eu reforço sempre: use somente informações reais e verdadeiras. Valorize a sua certificação, obedecendo desde o começo o seu código de ética profissional. Saiba que o PMI pode o tornar inelegível caso detecte informações falsas no seu processo.

IMPORTANTE: Para se tornar elegível, você deve apresentar no mínimo uma experiência em cada fase do projeto. Se você não comprovar, por exemplo, experiência no processo de encerramento, não será elegível à certificação.

Ao final do processo de reporte de experiência profissional você será solicitado a fornecer uma breve descrição das atividades desenvolvidas durante cada projeto reportado ao PMI. Esta descrição deve conter dados relevantes às atividades de gerenciamento de projetos. Evite “encher lingüiça”, procure ser objetivo nas colocações e utilize bullets ou listas numeradas para facilitar o entendimento. Outro ponto importante: todos os textos livres do processo deverão ser preenchidos em INGLÊS!

Sempre que terminar o preenchimento de uma experiência profissional, o site irá calcular o tempo total reportado e fazer uma checagem em todos os campos preenchidos. Será exibida uma tela apresentando o que está faltando para que a aplicação possa ser finalizada:

Terminada a etapa de reporte de experiência, passaremos às informações referentes ao curso preparatório para a certificação. O PMI exige que o candidato à certificação PMP assista ao menos a 35 horas de curso formal em gerenciamento de projetos (presencial) para que possa ser elegível à certificação.

Nos próximos passos você deverá inserir os dados da instituição que proveu o curso, bem como a sua carga horária.

Após preencher as informações sobre o curso preparatório serão apresentadas algumas questões opcionais, que solicitam informações sobre os motivos que o levaram à querer a certificação, indicações sobre o PMI e se você fez o curso em algum dos capítulos do PMI.

Terminado esse passo será apresentada uma tela onde você deverá colocar o nome que deseja que seja impresso no seu certificado. Este nome não precisará ser seu nome completo (eu por exemplo omiti meu nome do meio), mas obviamente não poderá ser em nome de outra pessoa.

Esta é a última tela de inserção de informações. A seguir será exibida uma tela onde constam todas as informações sobre o seu processo de aplicação: o que está OK e o que está faltando:

Quando todos os pré-requisitos estiverem preenchidos o botão Submit Application ficará ativo. Ao clicar nele seu processo será enviado ao PMI, que trará uma resposta em no máximo 5 dias úteis.

Como vocês puderam perceber, só o processo de aplicação para a certificação PMP já é bastante trabalhoso. Isso sem contar que nesse momento ainda nem começamos a falar sobre o conteúdo da prova!

O que posso dizer como depoimento é que apesar de complicado, difícil, chato e todos os outros “adjetivos” que podem ser atribuídos ao processo do PMI, conseguir a certificação é o coroamento de um trabalho, e compensa (e muito) o esforço.

A certificação PMP é a segunda certificação mais reconhecida no mundo. Só fica atrás da certificação CCNA da CISCO®. Isso traduz o enorme respeito que o mundo inteiro demonstra por essa instituição. Quem já fez a certificação CCNA sabe que o processo para chegar lá também não é simples.

Muito estudo, muita experiência, muito esforço, muita dificuldade, muitas aulas… Isso é o que faz uma certificação ter seu valor.

Caso você tenha curiosidade para verificar se alguém é ou não certificado, basta checar seu nome no link abaixo:

http://www.pmi.org/Certification/Credential-Registry.aspx

Obrigado por acessarem!

Saúde e sucesso,

Rodrigo Ramos, PMP

O que preciso fazer para me tornar um PMP?

2011-02-14T15:04:00.000-02:00

Nos grupos de discussão dos quais eu participo, nas rodas de conversas profissionais e nas conversas informais com colegas de profissão, tenho percebido que existe uma série de dúvidas a respeito do processo de aplicação para realizar o exame de certificação para o PMP. Muitos colegas ainda não conhecem os passos, e acabam sendo iludidos por empresas que oferecem soluções milagrosas para a certificação.

Esse post tem a intenção de esclarecer, através de uma simulação, todo o processo de aplicação para a certificação PMP do PMI. Se você está pensando em se certificar, preste atenção nas etapas pelas quais você deverá passar antes de poder agendar o seu exame.

Primeiros passos:

O primeiro passo para os futuros candidatos é acessar o site oficial do PMI internacional (www.pmi.org). Lá você poderá encontrar o guia PMP Handbook, um documento que explica todo o processo de aplicação para o exame, inclusive com os prazos para cada atividade.

O passo a passo para a certificação é mostrado na figura abaixo:

Em outras palavras:

Início do processo de avaliação (cadastro inicial – deve ser concluído em até 90 dias);
Avaliação do material enviado pelo candidato (a resposta é dada em até 5 dias úteis);
Pagamento da taxa do exame (você só pode marcar o exame depois de ter pago a taxa);
Processo de auditoria do material (a resposta é dada em até 5 dias úteis);
Início do período de elegibilidade (você pode fazer a prova em até 1 ano após a aprovação do material)

Como podemos notar, só o processo para se inscrever para o exame já é trabalhoso. A inserção dos dados no ambiente online do PMI também é complexa, e será detalhada passo a passo mais adiante.

Pré-requisitos:

O PMI exige uma série de pré-requisitos para que os candidatos sejam elegíveis à certificação PMP. Esses pré-requisitos variam de acordo com o nível de escolaridade dos candidatos. Eles são separados em dois níveis – candidatos com nível superior e candidatos com 2º grau completo. Os pré-requisitos são:

1. Para candidatos com formação completa em nível superior:

a. Mínimo de 3 (três) anos (ou 36 meses) de experiência profissional em gerenciamento de projetos;

b. Mínimo de 4500 horas dedicadas à liderança ou controle de atividades de projetos;

c. Mínimo de 35 horas de treinamento presencial em gerenciamento de projetos;

2. Para candidatos com 2º grau completo:

a. Mínimo de 5 (cinco) anos (ou 60 meses) de experiência profissional em gerenciamento de projetos;

b. Mínimo de 7500 horas dedicadas à liderança ou controle de atividades de projetos;

c. Mínimo de 35 horas de treinamento presencial em gerenciamento de projetos;

Quanto custa a certificação PMP?

Para os residentes no Brasil, o PMI tem a seguinte tabela de preços:

1. Para membros do PMI:

a. Exame informatizado (CBT): US$ 405,00;

b. Reagendamento (no caso de não passar na primeira tentativa): US$ 275,00;

c. Renovação da credencial: US$ 60,00;

2. Para não-membros do PMI:

a. Exame informatizado (CBT): US$ 555,00;

b. Reagendamento (no caso de não passar na primeira tentativa): US$ 375,00;

c. Renovação da credencial: US$ 150,00;

Como documentar minha experiência?

O site de aplicação possui uma área para documentar a experiência em gestão de projetos. Você deve documentar cada projeto individualmente.

Como foi descrito acima, devem ser comprovados o tempo de atuação em gerenciamento de projetos e as horas dedicadas a cada atividade.

Número de meses de experiência

Para o tempo de experiência, independente de você ter atuado em mais de um projeto simultaneamente, o período contado é linear, ou seja, se trabalhei em dois projetos durante o período de 1 ano, apenas 1 ano é contabilizado. O gráfico abaixo demonstra como o processo de contagem de tempo funciona:

No exemplo acima, o gerente de projetos trabalhou simultaneamente nos projetos 1 e 2 durante os meses de fevereiro a abril. O tempo gasto em ambos os projetos conta como 3 meses, não 6.

Número de horas dedicadas à liderança ou gestão de projetos

Considere todos os projetos com os quais você já trabalhou (dentro do período indicado no item anterior) e quantas horas foram investidas nas atividades de gerenciamento ou liderança de tarefas dos projetos.

Neste caso, se você tenha atuado em múltiplos projetos simultaneamente, todas as horas serão computadas.

Horas de treinamento em gerenciamento de projetos

Para poder fazer o exame para a certificação PMP, é necessário realizar ao menos 35 horas de treinamento presencial em gerenciamento de projetos, utilizando o PMBOK como referência. Não adianta ter tido treinamentos em SCRUM ou qualquer outra metodologia, também não são considerados nesta etapa treinamentos do tipo self-learning, é preciso ser treinamento presencial.

Dica: O treinamento, além de ser obrigatório pelo PMI, é fundamental. Não acredite que apenas a sua experiência de vida em gerenciamento de projetos será suficiente para passar na prova. Todos nós temos vícios de profissão, e esses vícios são exatamente o que o exame testa. Procure um centro de treinamento confiável para fazer o seu treinamento preparatório. Em São Paulo existe um número enorme de empresas oferecendo treinamentos. Procure informar-se sobre o histórico dessas empresas, se já tiveram alunos certificados e se possível se têm alguma referência para indicar.

O processo de report de horas no site do PMI é bastante complexo, e será o tema do próximo post. A dica é: monte uma planilha para guardar todas as informações. Deixar para fazer isso na hora da aplicação vai tomar um tempo enorme que poderia ser dedicado a outras atividades para preparação para a prova. No próximo post explicarei como reportar as horas em projetos no site do PMI, com prints das telas e todos os detalhes.

Passos finais:

Após completar todo o processo de comprovação de experiência, horas de trabalho, escolaridade, dados de projetos e outros detalhes, sua inscrição será avaliada pelo PMI. Nesse processo, que dura cerca de 5 dias úteis, duas coisas podem acontecer:

1. Seu processo ser aprovado sem comentários: é a resposta mais comum. Eles irão avaliar todo o material enviado, caso não encontrem nada de anormal o processo é validado e você se tornará elegível a realizar o exame. Eles irão enviar um email para a conta cadastrada, informando que a partir do dia xxxxx você tem o prazo de 1 ano para realizar a prova.

2. Seu processo ser encaminhado para auditoria: Nesse caso, o PMI irá solicitar que você encaminhe documentos que comprovem todas as informações inseridas no processo de submissão do material.

O que fazer caso seu processo caia em auditoria do PMI?

Antes de falarmos em auditoria, lembre-se que o PMI possui um código de conduta profissional, chamado PMI Code of Ethics and Professional Conduct. Se você pretende se tornar um profissional certificado, é bom conhecer esse documento. Nele constam as bases de ética e conduta que devem ser praticadas por todos os profissionais certificados. Parte desse documento trata da questão da veracidade das informações dadas ao PMI no processo de aplicação para a certificação, portanto, use seu bom senso e não coloque informações falsas no seu processo. Caso você seja enquadrado na auditoria e não puder comprovar as informações enviadas, sua inscrição será bloqueada até que você consiga justificar todas as informações reportadas. Isso significa que você pode ser impedido de se tornar um PMP devido aos seus próprios atos! Sendo assim, comece com o pé direito: insira somente informações verídicas e que possam ser facilmente comprovadas, adote o código de ética do PMI antes mesmo de ser um PMP.

Bem, agora voltemos à auditoria. Caso você seja enquadrado, precisará enviar ao PMI toda a documentação que comprove sua experiência e formação acadêmica para o PMI. Isso pode incluir (não se limitando a):

· Cópia do diploma de graduação;

· Declarações assinadas pelo seu superior (na ocasião do projeto em questão), declarando que você atuou no projeto conforme as horas apontadas na submissão;

· Cópias dos certificados de participação no curso presencial de gerenciamento de projetos que você freqüentou para poder se tornar elegível

Você terá até 90 dias para enviar as informações para o PMI, eles solicitam que todo o material seja enviado de uma única vez, em um único envelope, para agilizar o processo. Após o envio do material, a resposta da análise do PMI deverá ser enviada em até 5 dias úteis.

Lembro que você não poderá prosseguir com o processo de certificação até que todos os termos da auditoria tenham sido validados. Se você não conseguir validar todos os documentos junto ao PMI, você será reembolsado, de acordo com a política de reembolsos vigente à época da submissão do material. Hoje, caso você seja reprovado na auditoria, deverá pagar uma taxa de US$ 100,00, a título de despesas de processamento.

Política de reembolsos

Caso você desista da certificação durante o processo, você poderá solicitar um reembolso dos valores pagos ao PMI. Como título de despesas de processamento, o PMI irá reter o valor de US$ 100,00 caso seja solicitado o reembolso. Você poderá solicitar o reembolso até no máximo um mês antes de expirar o seu período de elegibilidade, ou seja, se você foi aprovado para realização do exame em 20/09/2011, você poderá solicita o cancelamento e o reembolso até 20/08/2012.

Caso esse período tenha sido ultrapassado, o PMI não irá receber a solicitação de cancelamento, portanto, não será aprovado qualquer reembolso.

Resumo da história

Como você deve ter percebido, o processo de aprovação inicial do PMI é bastante complexo. Isso porque ainda nem mencionamos o exame em si! Todo esse processo vale para que você se torne elegível a realizar o exame!

Se você tem como meta obter a certificação PMP, é importante guardar registros históricos dos projetos em que participou, ou participa, pois correr atrás dessas informações depois de algum tempo se torna difícil. Os gerentes das empresas acabam se desligando, perdemos contatos importantes que poderiam servir de apoio no caso de auditorias, esquecemos de quanto tempo investimos nos projetos... Por isso eu aconselho a todos que têm a intenção de se certificar que criem um processo de coleta das informações de projetos. Uma planilha de horas simples (existem vários modelos da própria Microsoft® online) ajuda, e muito, àqueles que pretendem se tornar PMPs.

No próximo post irei detalhar quais informações o PMI exige quando aplicamos online para a realização do exame. Creio que esse material ajudará a montar o seu conjunto de ferramentas para medição e apontamento de horas gastas em projetos daqui para a frente.

Por hoje é só pessoal. Em breve volto com a continuação deste post, detalhando o site do PMI e todo o processo de envio das informações do seu histórico.

Um forte abraço!

Saúde e sucesso,

Rodrigo Ramos, PMP

Certificação PMP: Um diferencial de mercado para profissionais e empresas

2011-02-13T10:02:00.004-02:00

A importância de uma certificação na área de gerenciamento de projetos é uma discussão freqüente entre profissionais do setor. Além de melhorar a empregabilidade, a certificação funciona como uma comprovação de que o profissional tem habilidades técnicas para atuar como gerente de projetos.

Entre as certificações existentes, destaca-se o Project Management Professional – PMP, considerada a quarta mais importante certificação profissional do mundo. Desde 1984, o Project Management Institute - PMI mantém um rigoroso programa de certificação PMP. O objetivo do programa é desenvolver a profissão de gerente de projetos e reconhecer os profissionais qualificados na área de gerenciamento de projetos. No âmbito do gerenciamento de projetos, a certificação PMP é a credencial internacional com maior reconhecimento no mercado.

Certamente a certificação PMP não é garantia de emprego para os candidatos, muito menos garantia de sucesso para os empregadores. No entanto, ao primeiro grupo, podemos afirmar que a certificação é, no mínimo, um critério de desempate entre candidatos com experiências semelhantes, e ao segundo grupo, podemos afirmar que um profissional certificado comprovou, ao menos em tese, milhares de horas de experiência, além de ter certamente dedicado boa parte de seu tempo ao estudo de gerenciamento de projetos.

É importante reconhecer que o mercado vem valorizando cada vez mais esta certificação, que atesta, entre outras coisas, a experiência do profissional em projetos, uma vez que para se tornar elegível a realizar o exame, o profissional deve comprovar 3600 horas de experiência, caso seja graduado em nível superior, ou 4500 em caso de técnicos e graduados no 2º grau.

No caso específico da área de TI, um dos segmentos que mais investem na metodologia de projetos, já não bastam mais as certificações técnicas, normalmente vinculadas a fornecedores específicos. Hoje, mais do que nunca, é importante que as organizações disponham também de colaboradores capazes de se orientar as equipes técnicas, de modo que os resultados dos projetos sejam melhores para a empresa e para os clientes. Para as empresas, a certificação PMP significa mais que profissionais capacitados. Tornou-se pré-requisito para um cenário altamente competitivo, muitas vezes exigido em licitações e concorrências, como uma maneira de comprovar o comprometimento de fornecedores com as boas práticas do gerenciamento de projetos.

Empresas que possuem profissionais PMP em seu quadro, dispõe de um forte diferencial no mercado. Com a concorrência cada vez mais acirrada e margens cada vez mais achatadas, ter profissionais que possam garantir o desempenho dos projetos dentro do planejamento (prazos, custos e qualidade), proporciona às empresas a possibilidade de redução de seu custo (conseqüentemente o aumento das margens de lucro), além de possibilitar a redução de preço de venda de seus produtos, proporcionando assim um diferencial importante em relação aos seus concorrentes.

Se você está pensando em investir na sua certificação, saiba que apenas a certificação não será garantia de emprego fácil: a experiência e a formação ainda são os pontos mais relevantes durante um processo de seleção, entretanto, a certificação certamente o credenciará a vagas diferenciadas, onde esse título é pré-requisito para a candidatura.

Se você já está empregado, e procura por uma recolocação ou uma promoção, vale a dica: aplique as práticas aprendidas durante o processo de certificação no seu dia-a-dia antes de partir para o mercado. Dessa forma vocês estará mais seguro e mais confiante no seu desempenho, afinal, nada substitui a prática e a experiência.

Outra dica importante: atingir essa certificação é uma questão de esforço pessoal, dedicação e estudo. Fique atento ao conteúdo oferecido pelos cursos, procure materiais adicionais e não pense que ler o PMBOK será suficiente para passar na prova... O PMI exige mais do que o conhecimento dos procedimentos descritos no guia. A prova o coloca em situações de problemas reais, para que você possa dar a melhor solução dentro das alternativas apresentadas. Por isso, invista seu tempo em simulados, para entender o “modo PMI de pensar”.

Se você já pratica o gerenciamento de projetos, cuidado com os vícios da profissão: nem sempre a nossa maneira de pensar e agir em determinadas situações é a melhor, considerando o ponto de vista do PMI.

Como ultima dica antes de me despedir fica um relato: passar não é impossível, longe disso, estudando e se dedicando, a recompensa virá antes do que você espera!

Saúde e sucesso!

Rodrigo Ramos, PMP

20 erros comuns de gerentes de projetos - Continuação

2011-02-10T10:46:00.002-02:00

11. Ignorar problemas

Ignorar os problemas é semelhante ao erro anterior de não querer pedir ajuda. No entanto, ignorar um problema também pode significar que o gerente do projeto pode resolver o problema, mas se recusa a resolve-lo logo ele toma forma.

Os problemas não desaparecem. Em vez disso, elas aumentam de tamanho, as possibilidades de uma solução diminuem, e os riscos podem aumentar significativamente. Saber da existência de um problema e não trata-lo, pode ser visto como incompetência do gerente de projetos pelo patrocinador, podendo inclusive culminar com a sua demissão.

12. Acreditar em milagres e salvadores

Talvez a razão mais comum para não pedir ajuda ou ignorar um problema é que o gerente do projeto está à procura de um salvador ou de um milagre para resolver o problema. Ainda que os milagres possam ocorrer, (um avanço tecnológico repentino, por exemplo) as chances de isso acontecer são muito, muito baixas.

Os gerentes de projeto precisam desenvolver, no início do projeto, uma estratégia para lidar com problemas. A esperança não é uma estratégia, muito pelo contrário, é uma visão míope de como evitar um problema.

13. Fazer promessas de recompensas

Gerentes de projeto inexperientes, muitas vezes fazem promessas de recompensas, mesmo sabendo que eles podem não ter praticamente nenhuma responsabilidade para a administração de salários. No entanto, acreditam que esta é uma forma eficaz de motivar a equipe. Os gerentes de projeto não podem fazer promessas de promoção, horas extras, bônus de atribuições de trabalho, futuro e de outras questões desse tipo, mas ainda assim insistem em fazê-lo.

Membros da equipe com mais experiência sabem o quê os gerentes de projeto podem e não pode prometer ou cumprir. O resultado é uma equipa com baixo moral, que tem pouca fé no gerente de projeto e não confia nele. Os membros da equipe também podem evitar a trabalhar para o gerente do projeto no futuro, sabendo de suas falsas promessas.

14. Não enxergar as dependências entre projetos

Gerentes de projeto inexperientes muitas vezes ficam tão encantados com os seus projetos, que não conseguem ver mais nada ao seu redor. O resultado é que eles acabam tomando decisões para o que interessam apenas ao seu projeto, ainda que essa decisão não seja de interesse da sociedade como um todo.

Os gerentes de projeto devem estar dispostos a tomar decisões de negócio/empresa, não apenas decisões de projeto, e isso requer a compreensão das dependências entre os projetos e os negócios em curso dentro da organização. Se o projeto tiver uma prioridade muito baixa em comparação com outros projetos, lutar para ter os melhores recursos da empresa pode não ser uma boa decisão se pensarmos do ponto de vista da organização.

15. Não informar ao cliente que ele está errado

Acreditar que o cliente sempre tem razão não é necessariamente correto em gerenciamento de projetos. Embora os gerentes de projetos queiram agradar os clientes, eles devem estar dispostos a dizer: "Sua decisão ou idéia está errada". Isto é particularmente aplicável quando os clientes pedem alterações de escopo, ou simplesmente querem mudar a direção do projeto, sem entender as ramificações e impactos dessa decisão. Há algumas pessoas do meio que acreditam que a palavra mais importante no vocabulário do gerente de projeto é "não".

16. Querer mostrar a todos “quem é o chefe”

Alguns gerentes de projeto se vêem como o "presidente" do projeto. Enquanto isso não é de todo ruim, os gerentes de projeto precisam perceber que isto é só no título que recebem, e às vezes pode vir com pouca autoridade real. O gerenciamento de projetos é freqüentemente descrito como a liderança sem autoridade.

Os gerentes de projeto que tentam mostrar que eles são “os caras” podem provocar os membros da equipe, principalmente aqueles que realmente entendem de gestão de projetos. Às vezes, os membros da equipe irão deixar que o gerente do projeto acredite que ele está no comando e, em seguida, usá-lo como responsável para todas e quaisquer decisões sobre o projeto, sabendo que o GP pode fazer a decisão errada.

17. Não conhecer bem a sua equipe

Pessoas que trabalham em equipes de projeto, principalmente nas organizações matriciais, sabem que têm uma “casa” em sua área funcional, depois que o projeto terminar. Os gerentes de projeto também sabem disso, e podem, portanto, cometerem o erro de achar que é desnecessário conhecer bem a equipe, uma vez que não terão interação com a equipe após o término do projeto.

O gerenciamento de projetos é um esforço de equipe. Se o GP não conhecer a equipe, alguns membros podem não se sentir parte da equipe. Conhecer a a equipe pode promover uma melhor comunicação, melhorar o trabalho, a cooperação e a confiança. Se acha que isto não é importante, tenta gerir um "projeto problemático" e ver o que acontece se não conhecer bem a sua equipe.

18. Não isolar a equipe dos problemas externos e da política

Fatores ambientais da empresa, especialmente a política, não deveriam afetar o desempenho da equipe no dia-a-dia. O gerente do projeto e o patrocinador do projeto devem isolar a equipe da política e outros fatores.

A política pode fazer os membros da equipe a perderem o senso de direção sobre o projeto, comprometendo seu desempenho. Além disso, os membros da equipe que não são “antenados” politicamente podem se envolver em problemas em que eles têm um conhecimento limitado, podendo piorar a situação.

19. Não dizer "Não"

A palavra "não" poderia muito bem ser a palavra mais importante no vocabulário do gerente de projeto. Isso vale para as relações com o cliente e com a equipe. Após o projeto ser autorizado, os clientes muitas vezes tentam forçar o GP a aceitar mudanças de escopo sem custo, sob o pretexto de mantê-lo “feliz”. Isso pode levar a conseqüências desastrosas para o projeto.

Outra momento oportuno para dizer “não” é quando os membros da equipe reclamam que estão sobrecarregados e tentam transferir parte do seu trabalho para o GP. Embora seja verdade que os gerentes de projeto são os gestores e executores, os gerentes de projeto devem conhecer suas próprias limitações e lembrar de se aterem às suas responsabilidades como gestores.

20. Escolher o “campo de batalha” correto

Para ser bom em fazer a guerra, é preciso saber quando atacar, quando a defender, e quando se retirar, para lutar novamente em uma melhor posição.Ggerentes de projeto inexperientes tendem a falhar em perceber quando lutar e quando desistir. Em vez disso, eles muitas vezes travam batalhas que deveriam ser lutadas por outros, ou até mesmo aquelas que não deveriam nem ser iniciadas. Os gerentes de projeto precisam saber qual jogo é bom para eles.

Bem, obviamente, esta lista não contém todos os erros possíveis e imagináveis. No entanto, ela fornece algumas orientações sobre os tipos de problemas que os gerentes de projeto normalmente devem enfrentar. Saber reconhecer essas situações e tratá-las adequadamente pode economizar um bom tempo e dinheiro.

Saúde e sucesso!

Rodrigo

Os 20 erros mais comuns de gerentes de projeto iniciantes

2011-02-10T10:25:00.001-02:00

Você leu o Guia PMBOK® inúmeras vezes, estudou, ralou e finalmente conseguiu ser aprovado no exame de certificação para gerentes de projetos, e agora, finalmente, você é um PMP!

No entanto, ainda comete erros... Bem, se você ainda não sabe, ao contrário do que prega o PMBOK, os gerentes de projeto não são infalíveis!

A maioria dos cursos de formação em gestão de projeto, mesmo aqueles com foco no PMBOK ®, reforçam a máxima: "Siga sempre as melhores práticas"...

O que normalmente não é ensinado pelos cursos e pelos professores focados em aprovar mais e mais PMPs, é o que NÃO fazer como um gerente de projeto.

A lista abaixo mostra vinte dos erros mais comuns que os gerentes de projetos inexperientes costumam cometer. Claro, existem muito mais erros dos que os vinte apresentados nesta lista, e alguns deles podem ser exclusivos para alguns tipos de projetos específicos. Ainda assim, a lista é um bom ponto de partida para entender por que muitos gerentes de projeto entrar em apuros por causa de suas próprias atitudes.

Essa lista foi publicada pelo site allPM.com, e foi escrita pelo guru do gerenciamento de projetos, Dr. Harold Kerzner.

1. Excesso de detalhes

Gerentes de projeto inexperientes tendem a ficarem maravilhados com as estruturas de divisão de trabalho. Um gerente de projeto recém-nomeado me pediu para rever a sua WBS (EAP) para um projeto de TI. O projeto – de trinta dias – tinha 340 pacotes de trabalho e alguns dos pacotes de trabalho foram divididos em minutos em vez de horas ou dias!

Enquanto o gerente de projetos estava orgulhoso de sua realização, com a criação de uma EAP de "nível micro", ele se esqueceu de considerar a quantidade de tempo e esforço exigidos pela equipe para gerenciar tamanho nível de detalhe. Os custos envolvidos para se criar, possivelmente, 340 números de contas e monitorá-las, em relação aos custos, orçamento, tempo e grau de conclusão poderia facilmente aumentar o custo de apoio à gestão do projeto em 50% ou mais!

Os gerentes de projeto devem estabelecer um nível de detalhes adequado para a EAP. Criar uma EAP altamente detalhada é um convite para microgerenciamento de um projeto, enlouquecendo os gerentes funcionais e toda a equipe de gerenciamento. A maioria dos gerentes de projeto atualmente não possuem conhecimentos técnicos adequados para criar uma EAP detalhada, sem assistência funcional. Apenas imagine uma reunião de kick-off de um projeto de 30 dias onde é apresentada uma EAP de 340 pacotes de trabalho???

2. Fingir saber mais do que realmente sabe

Em sua maioria atualmente, os gerentes de projeto possuem uma compreensão da tecnologia melhor do que a compreensão de comando, e ainda persistem na tentativa de tomar decisões técnicas sobre o projeto. Isso geralmente aborrece a equipe técnica e os gerentes funcionais, criando um clima de disputa do tipo “deixa eu mostrar quem é que manda aqui”.
O tamanho e a complexidade dos projetos de hoje em dia deveria deixar claro para os gerentes de projeto que eles devem – e precisam! – confiar pesadamente nas opiniões e argumentos dos especialistas e lideranças técnicas. Em alguns projetos, como em P&D, as atribuições de gerente de projeto podem requerer a liderança técnica em vez de um entendimento generalizado, mas isto é uma exceção e não a regra! Bons gerentes de projeto são conhecedores de suas limitações técnicas e, por esse motivo, não tentam impor uma solução sem se consultar primeiro com os verdadeiros especialistas no assunto.

3. Preparação de um cronograma ambicioso

Quanto mais inexperiente o gerente do projeto, mais otimista ele ou ela se torna quando o assunto é a elaboração do cronograma inicial. Cronogramas ambiciosos às vezes podem ser interessantes, mas eles são freqüentemente irrealistas e podem piorar a situação do gerente do projeto e da equipe. Os clientes nunca são avisados de que o cronograma é ambicioso e, portanto, acreditam que o cronograma seja realista e alcançável. Os clientes então se concentram nas datas marco e no agora. Quando as metas ambiciosas começam a escorregar para a realidade, você acaba com um cliente insatisfeito que quer saber que outras surpresas aparecerão durante o projeto.
Outro fator a considerar é o impacto sobre as estimativas funcionais. Cronogramas ambiciosos podem exigir que os membros da equipe executem atividades acima de sua capacidade de aprendizagem, ainda com uma carga superior àquela que ele recebe em sua estrutura funcional. Os gerentes funcionais podem não querer que suas estimativas e padrões sejam alterados. Além disso, cronogramas ambiciosos podem exigir os melhores membros da equipe funcionao, e isso pode não ser realista... Você sempre consegue os melhores recursos para os seus projetos?

4. Excesso de confiança em processos repetitivos

As empresas podem passar anos criando metodologias de gestão de projetos empresariais (EPM). A intenção é que a metodologia será utilizada em todos os projetos para todos os clientes e do berço ao túmulo. Embora a intenção tenha mérito, metodologias de EPM não levam em conta todos os possíveis problemas que podem existir em cada projeto. Ter total confiança e fé na expectativa de que os processos repetitivos vão resolver todos os seus problemas é um erro. Processos repetitivos aparecem na forma de diretrizes, formulários, modelos e listas de verificação. Processos repetitivos não substituem a atenção, a gestão eficaz de tomada de decisão ou a resolução de problemas. Eles são apenas ferramentas para o GP usar, e, como todos sabemos, os projetos são geridos por pessoas e não ferramentas.

5. Ignorar problemas

Todos os projetos têm problemas. Gerentes de projeto inexperientes acreditam que há tempo suficiente para resolver estes problemas e, normalmente, só descobrem que o custo de corrigir estes problemas, mais tarde, no ciclo de vida do projeto, foi significativamente maior do que se os reparos tivessem sido feitos nas fases anteriores do projeto.

Os gerentes de projeto não podem ser seletivos em relação aos problemas que têm para resolver. Todos os problemas do projeto devem ser tratados, e quanto mais cedo melhor! Embora seja verdade que os gerentes de projeto podem não ser capazes de resolver os seus problemas sozinhos, eles deveriam pelo menos saber que especialistas no assunto precisam para ajudá-los a resolver os problemas.

6. Não compartilhar responsabilidade com os Gerentes Funcionais

Nos primeiros anos da gestão de projetos, os gerentes de projeto possuíam uma formação técnica. Durante as atividades de alocação da equipe, os gestores de projetos negociavam recursos específicos os quais eram colocados sob a direção técnica do GP em vez do gerente funcional. O gerente funcional ainda mantinha o controle administrativo sobre os recursos. Hoje, os gerentes de projeto têm apenas uma compreensão da tecnologia e, portanto, devem negociar com os gerentes funcionais não os recursos para os projetos, mas as entregas de sua responsabilidade.

Deste modo, os recursos funcionais ainda permanecem sob a supervisão direta e controle do gerente funcional. Neste cenário, os gerentes funcionais devem estar dispostos a partilhar a responsabilidade pelo sucesso ou fracasso do projeto com o gerente do projeto.

Gerentes de projeto inexperientes acreditam que eles têm a responsabilidade sobre cada pessoa e sobre cada entrega do projeto, bem como sobre o seu sucesso. É um erro para o gerente do projeto não compartilhar esta responsabilidade com os gerentes funcionais. Às vezes, apoio executivo é necessário para impor essa responsabilidade partilhada, porque pode não ser a prática da sua cultura corporativa.

7. Gold Plating

A maioria dos gerentes de projeto quer “ganhar” o cliente. No entanto, há limites para o quão longe o gerente de projeto deve ir. O Gold-plating (fazer mais do que o contratado, sem alterar a relação do dito triângulo de ferro – escopo, custo e tempo) das entregas, após o escopo ter sido acordado, pode custar muito caro. Além disso, o cliente pode ser levado a acreditar que eles podem obter esses "add-ons" sem custos nos projetos futuros, pois um novo padrão foi estabelecido.

8. Falta de compreensão sobre o que os patrocinadores querem ouvir
Um dos requisitos para passar no exame PMP ® é uma compreensão da Gestão de Custos e, mais especificamente, as fórmulas para utilização do método de valor agregado (EVM). Embora haja mérito nisso, demonstrar as medições de valores são apenas uma parte do que os patrocinadores querem ouvir. É imperativo que, como parte da gestão dos stakeholders, o gerente de projetos conduza entrevistas com os interessados para saber quais as informações eles consideram importantes.

Todos os interessados podem querer um outro conjunto de métricas de monitoramento e indicadores chave de desempenho (KPI). O gerente de projeto pode achar que é necessário desenvolver um painel de desempenho diferente para cada um dos interessados. Isso pode incorrer em custos significativos, se não estiverem previstos no orçamento.

9. Não entender completamente os requisitos

Quanto mais inexperientes os gerente do projeto, maior é a probabilidade de ele usar sua própria interpretação dos requisitos, em vez de consultar opiniões dos peritos no assunto. Isso pode levar a uma desorientação na abordagem técnica e a um aumento nas mudanças, que podem custar caro nas fases posteriores do projeto.

Há outras causas que podem criar esse problema, um dos mais comuns é o momento para colocar o gerente de projetos no comando da situação. A 4 ª edição do Guia PMBOK® aborda a compreensão dos requisitos das partes interessadas. Muitas vezes, não é o gerente de projeto que participa das fases iniciais de discussão sobre o escopo, sendo esta etapa mais comumente delegada à equipe de vendas, que podem se ver obrigados a elaborar uma proposta para o cliente. O gerente do projeto, em seguida, herda os requisitos definidos pela equipe de vendas, e pode não estar plenamente ciente das premissas que foram consideradas para a elaboração da proposta.

10. Recusar-se a pedir ajuda

Um dos erros mais comuns cometidos pelos gerentes de projeto inexperientes, é a crença de que a pedir ajuda irá fazê-los parecer incompetentes aos olhos dos seus pares e da gestão. Nada poderia estar mais longe da verdade. Bons gerentes de projeto conhecem seus limites e, sempre que necessário, buscam ajuda com outras pessoas o quanto antes.

Recusar-se a procurar ajuda pode resultar em atrasos de cronograma e custos excessivos. Se o gerente de projetos demorar a procurar ajuda, o número de opções para corrigir o problema pode diminuir. Os patrocinadores devem se dispor a ajudar os gerentes de projeto o mais cedo possível, mas não espere que o patrocinador seja a solução para todos os problemas que o gerente de projetos não consiga resolver.

Continua.........

Bem vindos!

2011-02-10T10:12:00.000-02:00

Olá pessoal!

Como meu primeiro post, acho que vale uma apresentação:

Nome: Rodrigo Ramos

Profissão: Gerente de Projetos

Decidi investir uma parte do meu tempo em um blog sobre essa profissão por achar que ainda existe muito pouco material sobre o tema. Muito se fala em PMI, muito se fala em Project e Primavera, mas não se acha quase nada sobre todas as outras ferramentas e conhecimentos que precisamos para levar a vida de gerentes de projetos.

Vejo muitos aspirantes a GPs com uma visão um tanto distorcida sobre o que é essa profissão (agora legalmente reconhecida pelo Ministério do Trabalho), imaginando que o nome GERENTE na frente do seu cargo automaticamente significa poder e status

Durante os quase 8 anos que participei de equipes de projetos, tive GPs de diversos perfis. Aqueles que olhavam para o $$$, aqueles que olhavam para o relógio e aqueles que não estavam nem aí com o projeto em si, se preocupavam apenas em "deixar o cliente feliz"...

De todos eles retirei lições valiosas. De como ser e como não ser um bom GP. Acredito que nós estamos sempre aprendendo alguma coisa na vida, e que a busca pelo aprimoramento não pode parar nunca. Mas a lição mais valiosa que aprendi com um gerente que tive foi a de que a função de GP é ser recurso do projeto.

"Rodrigo, como assim??? Eu sou o gerente, não um recurso. Os outros é que tem que me obedecer!!! "

E aí está o primeiro engano dos aspirantes a GP... Pensar que são os "chefes" do projeto, quando de fato, precisam ser recursos facilitadores.

Na minha modesta opinião, a principal função do GP (assim como de qualquer outro gerente funcional) é prover para a equipe de trabalho todas as condições que eles precisam para produzir o trabalho do projeto (ou do departamento).

Isso inclui uma lista interminável de coisas, como:

Proteger a equipe de influências negativas externas;
Garantir a disponibilidade de recursos (não só computadores, mas também café, água, banheiro);
Servir à equipe - no mais amplo sentido da palavra.

O bom GP consegue que sua equipe realize coisas que, sem a sua presença, não realizaria. Isso não está no PMBOK, muito menos no help do MS Project (existe help no Project????)... Essas coisas normalmente se aprendem com a vida... E tem nome: liderança.

Liderar não é chefiar...

O chefe ordena - O lider convence.
O chefe pune - O lider ensina.
O chefe aponta culpados - O lider aponta os resultados
O chefe critica você - O lider critica suas idéias

Durante os posts vou tentar dar algumas dicas para evitarmos as armadilhas da vida cotidiana do Gerente de Projetos. Nossa vida não é glamurosa. Não somos gerentes de fato, somos apenas um membro de uma equipe.

Lembre-se sempre da sua equipe. Você e o projeto dependem dela, portanto, ela é o seu bem mais valioso! Reconheça os ganhos, minimize as derrotas, seja um bom líder para a equipe e as suas chances de ser bem sucedido nos seus projetos será multiplicada.

Sucesso e saúde!

Rodrigo