O objetivo desde blog é contribuir como um guia de boas práticas para o gerenciamento de projetos.
Se você é um profissional, um curioso ou um apaixonado pela área aproveite o nosso material e, antes de ir, deixe a sua contribuição para crescermos juntos.

quinta-feira, 30 de junho de 2011

Recuperação do Alaska - Encontre a cidade perdida

O que você faria se descobrisse que um filantrópico milionário está procurando um gerente de projetos para contratar?

Você ganharia uma passagem gratuíta para o Alaska nos EUA, e passaria dois dias em alto mar na Baia de Bristol, e talvez participaria do time que está a procura de uma cidade perdida. Você trabalharia com uma variedade de Stakeholders que detêm todas as mais modernas tecnologias, além de um enorme orçamento disponível. O tempo é um pouco apertado, mas como um excelente gerente de projetos, você poderá ajudar o time a realizar muito dentro do tempo que possuem, como a tentativa de descobrir a origem de um antiquíssimo artefato encontrado no fundo do mar de Aleutian, na costa do Alaska.

Você se interessaria?

A Recuperação do Alaska, que possui o título original "The Alaskan Recovery Series", é uma série de cursos de simulação, em que você atua como gerente de projetos em um projeto de expedição no fundo do mar.


O objetivo é que você coloque seu conhecimento do Guia PMBOK®, 4 ed., em prática através do curso, em um emocionante cenário de simulação perfeito. A simulação desafia você e permite que você tenha sucesso, ou não, no projeto, permitindo que você faça tudo novamente, caso perceba que pudesse ter tomado um caminho diferente.

A série de cursos apresenta um cenário real de gerenciamento de projetos, onde o gerente de projetos poderá gerenciar arqueologistas, acadêmicos, mergulhadores e até a tripulação de um navio. Aprendendo como tratar com pessoas e situações difíceis, exatamente como é esperado por você na vida real.

O curso é uma séria baseada em oito áreas de conhecimento do Guia PMBOK® e há numerosos pontos de decisão que você precisa tratar ao longo do curso. Sendo que duas pessoas podem fazer esta simulação e terem cenários diferentes, devido a suas decisões serem diferentes, liderando então por diferentes caminhos em todo o curso.

Você, como gerente de projeto, executa o projeto e determina o seu sucesso, ou não tão sucesso, ao encerrar este projeto.

Este é um curso de nível intermediário, onde termos e definições não são explicadas, sendo esperado que você saiba os significados dos termos e conheça quais documentos precisarão ser aplicados para completar o projeto.

A série de cursos "A Recuperação do Alaska", em formato de simulação, já está em seu segundo episódio nomeado de Gerenciamento de Tempo do Projeto, com o título original "Project Time Management". O primeiro episódio foi entitulado de Gerenciamento de Escopo do Projeto, com o título original "Project Scope Management".

Ambos podem ser comprados através do próprio site do PMI Internacional, na sessão de desenvolvimento profissional, na área de e-Learning. O valor de cada episódio para membros é de 175 doláres, e para não membros o valor é de 225 doláres. O curso ainda permite o seu acesso durante 1 ano, e fornece 3.5 PDUs por episódio para os que querem manter suas certificações.

_________________________________________________________________
Texto traduzido livremente por Fábio Cruz, autor deste blog, a partir do artigo "Find the Lost City - and Learn Project Management Skills", publicado na edição de julho de 2001 da PMI Today.

terça-feira, 28 de junho de 2011

Workshop Scrum - parte 1/3

A Paradigma, empresa que eu presto serviços atualmente na área de gerenciamento de projetos, promoveu nos últimos dias 16, 17 e 18 de junho, um Workshop sobre o tema de Gerenciamento Ágil de Projetos de Desenvolvimento de Software com Scrum.

A empresa Innovit, na qual algumas de suas especializações são os treinamentos de gerenciamento de projetos e Scrum, foi a contratada para realizar o Workshop com sobrenome de Treinamento.


O evento teve o seu cenário ideal concretizado logo no primeiro dia, onde toda a área técnica da empresa, acompanhada pela sua gerência, direção e presidência participaram do Workshop. Este é o cenário ideal quando uma empresa resolve trabalhar com Scrum, pois este arcabouço tem como uma de suas características, o rompimento de conceitos e a quebra de ideologias pré-estabelecidas de trabalho, então é preciso que toda a empresa participe do processo de sensibilização, conscientização e culturalização.

A Paradigma começou muito bem no apoio a estas mudanças, e conseguiu levar mais de 40 de seus principais colaboradores para o evento, e eu estava entre eles.

A Innovit levou Nicolai Albuquerque para ministrar os quase 3 dias deste Workshop in Company. Nicolai é um dos principais profissionais brasileiros na área, que além de incentivadorentusiasta de boas práticas de gerenciamento de projetos como o PMI e o Scrum, é atuante na área de gerenciamento de projetos, sendo um dos sócios e dirigentes da própria Innovit, consultor em projetos por todo o Brasil, instrutor em instituições como FGV e atual presidente do chapter de Santa de Catarina do PMI.

Nicolai, já vinha realizando um trabalho anterior na Paradigma, onde fez entrevistas internas com vários profissionais para a identificação de problemas, falhas, fraquezas, qualidades e forças, do nosso processo interno de gestão, execução e controle de projetos. Com isso ele teve condições de levar um Workshop mais direcionado as necessidades da empresa contratante e de seus interessados, que éramos nós.

No primeiro dia, ele fez um trabalho de sensibilização, conseguindo nos mostrar através de debates entre nós mesmos, quais eram as nossas maiores necessidades de melhoria, e onde estavam as nossas principais deficiências no gerenciamento e execução de projetos.

Nicolai também fez um trabalho de conscientização sobre quais as principais forças do gerenciamento ágil de projetos com o Scrum, e quais seriam os ganhos que poderíamos ter com a sua aplicação em nosso projetos.

A partir deste momento o real resultado deste Workshop tomou forma e se mostrou a todos os presentes, quando a participação e a vontade de melhorar, mudar e inovar de praticamente toda a Paradigma ficou evidente. Os debates saudáveis foram intensos, as discussões entusiasmadas foram inúmeras e as respostas seguras e motivantes eram soltadas a todos os momentos por Nicolai, que nos apresentou pela primeira vez o relógio acreano ... que vou explicar em um outro momento.

Fluxo Scrum

Antes de fechar o dia, ele nos passou rapidamente uma idéia geral de todo o Framework do Scrum, focando nos papéis, regras, cerimônias e o fluxo Scrum.

Estes últimos serão os temas dos próximos posts que deixarei aqui, sobre este Workshop no qual tive o prazer de ter participado.

domingo, 12 de junho de 2011

Resposta aos riscos

Após identificar os riscos de seu projeto e analisá-los, chegou o momento de planejar as respostas a estes riscos em potencial.

Esta etapa do planejamento aos riscos tem como objetivo desenvolver opções e ações para aumentar as oportunidades aos riscos com impacto positivo, e reduzir as ameaças aos riscos com impacto negativo.

Antes mesmo de pensar nas respostas é preciso ter em mente que é importante delegar o acompanhamento de cada risco a um responsável, que será conhecido como o dono do risco (Risk Owner), e será também o responsável pela resposta ao risco, sendo que estas respostas devem ser adequadas, eficientes, realistas, acordadas e oportunas.

De acordo com o tipo do risco, há estratégias diferentes para o tratamento de sua resposta, dentre as estratégias temos:
  1. Estratégias para riscos negativos ou ameaças:
    • Eliminar: Alterar o plano do projeto para eliminar totalmnte o risco, protegendo os objetivos do projeto dos impactos deste risco eliminado.
      • exemplo: Transferir a festa do campo para um salão coberto, eliminando o risco de chuva ou mal tempo.
    • Transferir: Transferir o risco para um terceiro, transferindo os impactos e a responsabilidade. É preciso ter em mente que o risco não é eliminado, e quase sempre envolve o pagamento de prêmios a parte que está assumindo o risco.
      • exemplo: Contratação de um seguro de carro ou residência.
    • Mitigar: Reduzir a probabilidade ou impacto de um risco até um nível aceitável.
      • exemplo: Ir ao banco sacar 100 mil reais no caixa eletrônico, acompanhado de seguranças fortemente armados e sair de lá em um carro blindado.
    • Aceitar: Quando não é possível aplicar nenhuma das outras estratégias, e a equipe do projeto decide correr o risco.
  2. Estratégias para os riscos positivos ou oportunidades:
    • Explorar: É o desejo de garantir que a oportunidade aconteça e se concretize durante o projeto.
      • exemplo: Certificar um profissional para a participação da empresa em uma licitação que exige tal certificação;
    • Compartilhar: Unir-se a um ou mais terceiros que tenham maior qualificação para capturar a oportunidade em benefício do projeto;
      • exemplo: Montar um consórcio de empresas com parceiros que já tenham as qualificações exigidas para a participação em uma determinada licitação.
    • Melhorar: Procurar facilitar ou aumentar as possibilidades de que a oportunidade aconteça;
      • exemplo: Finalizar o projeto atual dentro dos objetivos do cliente, pensando em futuras oportunidades de novos projetos.
    • Aceitar: Quando não é possível aplicar nenhuma das outras estratégias, e a equipe deseja a oportunidade mas não tem o objetivo de aplicar esforços para que ela aconteça.
É muito importante que nenhum risco fique sem dono e sem estratégia de resposta, e principalmente que os riscos sejam levados sempre as reuniões de projeto para acompanhamento e monitoramento de sua situação, probabilidade e gatilho.

Nunca pense que um risco não pegará o seu projeto, se você ou sua equipe o percebeu, pode ter certeza que ele também percebeu o seu projeto, e estar preparado para um risco é sempre melhor do que reagir a sua ocorrência.


Faça como o ratinho acima, antecipe, identifique e planeje, só assim você terá o objetivo do seu projeto sob controle.

Se você quiser saber ainda mais sobre riscos, e principalmente como o PMBOK® os trata, visite a sessão Planejar o gerenciamento dos riscos do grupo Planejamento - Passo3, deste mesmo blog.

segunda-feira, 30 de maio de 2011

Sala de guerra

A técnica de agrupamento é mais conhecida na área de gerenciamento de projetos como Sala de Guerra, que vem do inglês War Room, também conhecida como Sala de Crise.

A teoria da Sala de Guerra é uma das ferramentas e técnicas contidas no Guia PMBOK®, no grupo de processos de Execução do projeto, mais precisamente no processo Desenvolver a Equipe do Projeto.

Desenvolver a Equipe do Projeto tem como foco principal aumentar as capacidades individuais e de grupo para que a equipe funcione realmente como um time, por exemplo incentivar a ajuda mútua quando houver desequilíbrio na carga de trabalho dos integrantes da equipe.

Sendo que o trabalho em equipe é um fator essencial para o êxito do projeto, cabe ao gerente de projetos criar um ambiente que facilite o trabalho em equipe, e Desenvolver a Equipe do Projeto é fazer a equipe trabalhar cada vez mais como um time, e os objetivos de promover este desenvolvimento incluem:
    1. Aprimorar os conhecimentos e as habilidades dos membros do time para reduzir custos, cronograma e melhorar a qualidade das entregas concluídas.
    2. Aprimorar os sentimentos de confiança e consenso entre o próprio time, melhorando a motivação e reduzindo os conflitos.
    3. Criar uma cultura de equipe dinâmica com espírito de equipe e cooperação permitindo o treinamento e mentoria entre os próprios membros da equipe, além do compartilhamento de conhecimentos.
Uma das técnicas sugeridas pelo Guia PMBOK® para atingir o objetivo de Desenvolver a Equipe do Projeto é o agrupamento, que é:
  • A técnica de colocar alguns ou todos os membros da equipe em um mesmo local físico para maximizar o trabalho em grupo e a construção da equipe, podendo ser durante o projeto inteiro ou em ocasiões estrategicamente importantes.

  • O exemplo mais clássico desta técnica é a Sala de Guerra, conhecida também como War Room, ou Sala de Crise.
Como gerente de projetos, já apliquei algumas vezes a técnica da Sala de Guerra, e obtive bons resultados, inclusive com retorno positivo da equipe envolvida com este agrupamento.

Uma dica que eu deixo para todos os que se interessarem pela aplicação da War Room é a comunicação clara com a equipe, antes do agrupamento ser realizado, deixando claro os objetivos e os resultados esperados com a aplicação desta técnica de Desenvolvimento da Equipe do Projeto.

* Para conhecer mais sobre as técnicas de Desenvolvimento da Equipe do Projeto, clique aqui e visite o item de mesmo nome, na sessão Executando deste mesmo blog

sábado, 28 de maio de 2011

Preparotório PMP/ CAPM em Floripa

Mais uma turma foi confirmada do preparatório para Certificação PMP/CAPM.

A Euax iniciará nos dias 03 e 04 junho, em Florianópolis/SC, uma nova turma do preparatório para certificação PMP/CAPM.

Este foi o curso que eu realizei quando me preparei para a certificação, recebi um material muito bom de autoria da própria escola, além de simulados e de uma cópia autorizada e oficial do Guia PMBOK® em português.

No Flyer abaixo há mais informações sobre o curso:

Para maiores informações e inscrições:
www.euax.com.br
Tel.:(47) 3802-7399 com Cristiane Rodrigues.
Condições especiais para Grupos*
*Associados ao PMI®, ASSESPRO, ACATE, CDL Florianópolis tem desconto de 10%

A Euax é um provedor credenciado como R.E.P. pelo PMI®, ou seja, nossos treinamentos passam por todo o processo de avaliação e homologação do PMI®.

quinta-feira, 26 de maio de 2011

Cadê o gerente? ep. 2

Para o segundo capítulo da série "Cadê gerente?", escolhi um tema importante e que ainda é muito ignorado e negligenciado no mundo de projetos: A documentação.

Uma obra de duplicação da rodovia SC 401 na cidade de Florianópolis, iniciada a cerca de 1 mês, está gerando enormes transtornos a comunidade local.

O primeiro problema foi causado quando a empreiteira responsável pela obra danificou a rede de abastecimento de água, deixando mais de 123 alunos sem aula em uma escola da região.

Outro problema ocorreu na quinta feira (19) quando a mesma empreiteira, ao demolir uma das casas desapropriadas, destruiu também uma central telefônica da Oi. O incidente deixou mais de 800 telefones sem funcionar até o domingo (22), prejudicando moradores e comerciantes locais que ficaram sem telefone, internet e máquinas de pagamento por cartões.


Ao ser questionado sobre os incidentes, o responsável pela obra, argumentou que não havia plantas das instalações telefônicas e de abastecimento de água na região, e que estes imprevistos poderiam acontecer.

Bom, percebe-se rapidamente como projetos que parecem ser desconectados e independentes, podem ser na verdade 100% dependentes e interligados, tornando as documentações mais importantes, além de essenciais e imprescindíveis. Este é um exemplo claro de um projeto passado, que precisava ser bem documentado para que no futuro fornecesse informação a um novo projeto.

Vale lembrar também, que uma boa documentação não é realizada apenas quando os documentos são criados, mas também na forma que são armazenados, organizados e recuperados no futuro. Será que as plantas mencionadas não existiam, não foram encontradas ou não foram disponibilizadas em tempo hábil?

Outro ponto fundamental é que o gerente do projeto em execução precisa se armar de toda a documentação existente dos projetos passados, para que riscos como estes sejam mitigados. Será que neste caso o responsável pela obra atual solicitou as plantas às empresas anteriores? Será que a análise dos documentos de projetos anteriores estava no plano de projeto?

Lembre-se que uma documentação mínima necessária para que o projeto seja entendido, realizado, consultado e utilizado futuramente, deve sempre ser realizada. Seja em projetos de software ou de engenharia, precisamos de especificações, de plantas e de registros do projeto. Só assim no futuro, alterações ou novos projetos serão realizados com segurança, eficácia e eficiência.

Não pule etapas acreditando que um documento é desnecessário, ou é perda tempo. Acredite, lá na frente algo terá que ser refeito devido a falta de um ou mais documentos, e nunca se esqueça que refazer é sempre mais caro do que fazer.

Não esqueça do recado e sempre pergunte: Cadê o gerente?

domingo, 22 de maio de 2011

Evento MundoPM e FIA

O gerenciamento de projetos em larga escala exige um evento a altura, por isso um seminário promovido pela revista MundoPM & FIA convida todos os interessados para participarem do Special Day FIA - Fundação Instituto de Administração.

É um programa voltado para o gerenciamento de projetos em larga escala e que tem como público-alvo gestores de projetos e programas, com os seguintes objetivos:
  • Atualização e capacitação profissional em projetos em larga escala;
  • Apronfudamento da complexidade e dinâmica do gerenciamento de projetos de grande porte;
  • Como gerir grandes quantidades de pessoas envolvidas e de diferentes nacionalidades;
  • Análise da cadeia de eventos críticos nos projetos e seus cronogramas.
Os tópicos que serão abordados pelo evento são:
  • Projetos de reconstrução nacional;
  • Aplicativos para gestão corporativa de projetos;
  • Gestão de projetos globais;
  • Modelo de gestão da maturidade em projetos;
  • CCPM - Critical Chain Project Management (Corrente crítica/ Teoria das restrições);
  • Casos de sucesso de CCPM em projetos;
  • Avanços em CCPM, experiências grupo Goldratt;
  • O presente e o futuro do gerenciamento de projetos;
  • Execução e apontamento de avanço físico e financeiro orientada por pacotes de trabalho;
  • Uso de CCPM em gerenciamento de portfólio de projetos.
Os principais palestrantes convidados são:
  • João Carlos Boyadjian, USP, FIA, FGV, ETEC, FATEC e CPLAN;
  • Roberto Sbragia, FEA/USP, FIA, University of Texas at Dallas/EUA;
  • Ivete Rodrigues, FEA/USP, FGV, FIA e Bentley College at Boston/EUA;
  • Richard Massari, Goldratt e Garrett;
  • Humberto Baptista, Vectis Solutions, Goldratt;
  • Carlos Morais, PMP, POLI/USP, FIA e FEA/USP;
  • Antonio Cesar Amaru Maximiano, USP e Université François Rabeleis/Tours/France;
  • José Finocchio Jr, PM2.0, FGV, FIA, FEA/USP;
  • Farhad Abdollahyan, École des HEC/Paris/France, Université de Lille III, George Washington University, Universidad Nacional de Rosario/Argentina, FI/CO e ASAP (SAP), PMP, OPM3, MoP, MSP, PRINCE2, P3O, Odebrecht, GTECH, FIA, ESI International, PMI, MundoPM;
  • Sérgio Molina, Solution Sales Professional (SSP) e EPM Business Solutions at Microsoft.
A programação pode ser conferida abaixo:


Este evento ocorrerá nos próximos dias 30 e 31 de maio, das 8:00 às 17:00 em São Paulo, na sede da Microsoft Brasil na av. das Nações Unidas 12901, 31° andar - Auditório da Microsoft.

As inscrições podem ser feitas pela internet no site da MundoPM, e os valores variam de R$ 1.062,00 à R$ 1.250,00.

Maiores informações acesse diretamente o site do evento em MundoPM. Não deixe de aproveitar esta grande oportunidade para ampliar ainda mais seus horizontes profissionais.

Riscos positivos

Dando continuidade ao tema de riscos, vamos falar agora de um assunto ainda não muito abordado nos projetos, os riscos positivos, também conhecidos como oportunidades.

Ao contrário dos riscos negativos que geram ameaças com consequências negativas, levando a prejuízos nos projetos, os riscos positivos são eventos que geram oportunidades com consequências positivas, e costumam gerar benefícios, melhorias ou ganhos para o projeto.

Quando ouvimos a palavra risco, inconscientemente pensamos em eventos que podem gerar prejuízos, mas nem sempre é assim. Precisamos desmistificar esta idéia, e ter em mente que um risco pode gerar excelentes oportunidades de ganhos, melhorias e até crescimentos nas organizações relacionadas ao projeto.

Os riscos positivos são oportunidades que devem ser aproveitadas quando identificadas, vamos a alguns exemplos:
  • Um produto inovador que está planejado para ser entregue em fevereiro do próximo ano, pode gerar altos ganhos ao fabricante, e antecipar um crescimento esperado se entregue antes do natal do mesmo ano.
  • O término de um projeto importante, dentro do prazo esperado pelo cliente e com alto valor agregado, pode gerar uma sociedade entre as duas empresas, gerando uma forte parceria em um mercado específico.
Os riscos positivos, ou oportunidades, precisam ser planejados. Este planejamento pode envolver a maximização das chances do evento ocorrer e gerar a consequência positiva esperada. Um evento totalmente desconhecido, ocorrido por pura sorte ou acaso, não deve ser considerado um risco positivo.

O gerenciamento das oportunidades é tão importante quanto o controle das ameaças. Atualmente as ameaças são mais frequentes e ocorrem em maior número, além da sua ocorrência poder prejudicar o projeto e acabar com um negócio. No entanto, o que você faria se visse a sua frente uma placa como a mostrada abaixo?


Seria difícil não virar a direita não é? Uma oportunidade pode gerar um negócio novo, um projeto novo, um novo mercado, e ainda oportunidades em cima de novas oportunidades, portanto não deixe de analisar, planejar e controlar seus riscos positivos, se bem planejados eles podem te levar ao sucesso.

Se você quiser saber ainda mais sobre riscos, e principalmente como o PMBOK® os trata, visite a sessão Planejar o gerenciamento dos riscos do grupo Planejamento - Passo3, deste mesmo blog.

Na sequência, e em breve, eu falarei de como planejar as respostas à todos os riscos identificados, não perca!

sábado, 7 de maio de 2011

Riscos Negativos

Antecipar, na minha opinião, é a palavra mais importante do gerenciamento de projetos, e quando se gerencia os riscos, se aplica profundamente o conceito da palavra antecipar. Um gerente de projetos precisa se preparar para os riscos, antecipar os riscos e por fim manter os riscos sob controle.

Risco, segundo o PMI®, é um evento ou condição incerta que, se ocorrer, tem um efeito positivo ou negativo sobre pelo menos um dos objetivos do projeto.

Bom, o que isso significa na prática?

Todos os ambientes onde os projetos estão inseridos não são 100% controlados, e por isso há incertezas, e estas incertezas se tornam riscos. Vamos a alguns exemplos de riscos negativos, também conhecidos como ameaças:
  • Quando se constrói uma casa, a área externa é altamente afetada pelas condições climáticas, uma chuva, ou uma semana de chuva pode atrasar o enchimento de uma laje de concreto;
  • Um campeonato de surf, depende das condições das ondas, sem o mar não colaborar uma etapa pode ser atrasada em dias;
  • Uma viagem por uma rodovia de 500km, que possui apenas 1 posto de gasolina na metade do trajeto, pode ser interrompida caso este posto esteja fechado;
  • Uma etapa de um projeto que depende exclusivamente de uma única pessoa, pode ser altamente prejudicada se a pessoa ficar doente, sofrer um acidente ou precisar se ausentar por um período.
Como podem ver, são todas situações incertas, que não há como prever com 100% de certeza e muito menos ter o controle absoluto sobre os fatos. Neste momento é que entra o fator antecipação.

Um gerente de projetos, precisa prever estes riscos e se preparar para eles, não podendo se dar ao luxo de ser pego de surpresa por um risco não previsto. Os riscos não previstos são uma das causas de atrasos e fracassos em diversos projetos.

Um triste, mas ótimo exemplo foi o atentado de 11 de setembro, onde várias empresas faliram, porque além de perderem o seu board diretivo, ainda perderam todos os seus dados, informações e backups que estavam guardados e "seguros" na torre ao lado. Quem poderia prever que as duas torres seriam derrubadas ao mesmo tempo? Pois é, depois de 11 de setembro muitos pensamentos mudaram a respeito de riscos.

Por isso um GP não pode conduzir um projeto, seja ele qual for, sem gerenciar os riscos. Portanto, durante o planejamento do projeto pense nos riscos existentes, converse com profissionais especializados, obtenha informações da região como clima, fornecedores e mão de obra, olhe para o seu cronograma e perceba onde estão as atividades e prazos críticos, identifique os riscos possíveis e iminentes que podem afetar o seu projeto, e trace estratégias de respostas a estes riscos.

Por quanto tempo você ficaria embaixo deste morrinho ai, e ignoraria os riscos dele desmoronar?


Então não espere o seu projeto desmoronar, lembre-se que, se você não controlar os riscos, eles vão te controlar e descontrolar o seu projeto.

Se você quiser saber ainda mais sobre riscos, e principalmente como o PMBOK® os trata, visite a sessão Planejar o gerenciamento dos riscos do grupo Planejamento - Passo3, deste mesmo blog.

Na sequência e em breve eu falarei dos riscos positivos, e de como planejar as respostas à todos os riscos identificados, não perca!

domingo, 24 de abril de 2011

O técnico e o gerente!

O gerente de projetos é o responsável pelo fracasso de um projeto, e toda a equipe do projeto é a responsável pelo seu sucesso.

A partir desta frase podemos refletir sobre diversas situações, responsabilidades e ações de todos os envolvidos com um projeto. Com ela eu também gostaria de homenagear um técnico de sucesso que levou a sua equipe a conquista de um título nacional em seu esporte.

Foto retirada do site da UOL. Clique aqui para ver a foto e a matéria associada.
Giovane Gávio técnico do time de volei do SESI-SP, como pode ser visto na foto acima, comandou a sua equipe rumo ao título da superliga nacional em 2011. Será que podemos dizer que ele gerenciou a sua equipe?

Podemos sim, e na minha opinião é um ótimo exemplo para explicar a frase que eu iniciei este post.

No esporte, o técnico tem uma grande responsabilidade e atua como gerente boa parte do tempo, contratando os jogadores certos para as posições apropriadas, escalando a equipe corretamente para cada jogo, montando a estratégia para cada adversário, além de dirigir, facilitar, motivar, incentivar, coordenar e controlar a sua equipe durante todo um campeonato. É ou não é um gerente?

Hoje mesmo me lembraram que os técnicos de futebol na europa são chamados e contratados como managers.

Giovane sabe muito bem da cobrança que há sobre os técnicos no Brasil e no mundo, quando os times que comandam são derrotados vêem as críticas, as pressões e até as demissões, porque no esporte realmente é levado muito a sério a questão levantada inicialmente, onde os gerentes (técnicos) são os responsáveis pelo fracasso de um projeto, que no caso dos esportes em equipe, são os campeonatos.

Por outro lado o técnico não é tão aclamado quando o seu time é campeão e obtêm o sucesso do projeto que era a conquista de um título. O técnico é muitas vezes considerado como apenas mais um da equipe, e mais um dos responsáveis pelo sucesso, e não o único responsável. Onde também se enquadra muito bem a questão inicial, onde toda a equipe é a responsável pelo sucesso do projeto.

O recado que pretendo deixar é para que estes exemplos do esporte também sejam levados aos projetos comuns, pois muitas vezes o gerente é o único que leva a "fama" de um projeto bem sucedido, e muitas outras vezes membros da equipe são prejudicados e até punidos com a demissão pelo fracasso de um projeto, mas onde estava o gerente do projeto quando o membro da equipe cometeu o erro que levou o projeto ao fracasso?

Para terminar desejo sucesso aos nossos técnicos brasileiros nas mais diversas modalidades esportivas, e também aos nossos gerentes de projetos nas mais variadas áreas.

Façam como os técnicos vencedores, pratiquem, experimentem, ousem, mas também escutem, estudem, aprendam e se preparem, além é claro, de se armarem com os melhores em cada posição, buscando sempre o sucesso de seus projetos e podendo comemorar na entrega, como a equipe da foto abaixo.

Foto retirada do site da UOL. Clique aqui para ver a foto e a matéria associada.

sexta-feira, 22 de abril de 2011

Cadê o gerente?

Este é o primeiro capítulo da série de posts que vou entitular de "Cadê o gerente". O objetivo será mostrar exemplos de diversos tipos de falhas ocorridas em projetos reais. Espero que gostem, e que principalmente provoque discussões e reflexões sobre o que é gerenciamento de projetos, e especialmente qual é o papel do gerente de projetos.

Durante as últimas reformas da Catedral de Florianópolis, foi construído um acesso de cadeirantes. Quando pensamos nestes acessos especiais e exclusivos, pensamos logo em caminhos para facilitar, melhorar e permitir o acesso a locais antes inacessíveis ou de difícil acesso.

Bom, parece que o objetivo inicial do projeto de instalação de um elevador de cadeirantes, para acesso à Catedral de Florianópolis era este, porém ao vermos a foto abaixo, tirada esta semana após a conclusão da obra, podemos ver que o projeto não foi muito bem sucedido.

Foto: ClickRBS - Clique aqui para ver a matéria
Cadê o gerente deste projeto? Podemos ver em apenas uma foto, um poste na frente da rampa de acesso, e uma dúvida que me veio rapidamente a cabeça: "Para que a rampa se instalaram um elevador?".

Facilmente podemos identificar algumas falhas de planejamento, como por exemplo:
  • Se havia um poste ali, porque não foi feito o acesso em outro local?
  • Se o melhor local para o acesso era este e foi acordado a retirada do poste, o que houve que o poste ainda continua ali?
  • A rampa não é muito inclinada para um acesso de cadeirante? Um idoso cadeirante conseguiria subir esta rampa sozinho? Ou a rampa foi feita apenas para cadeirantes acompanhados por alguém os empurrando?
  • Ao descer a rampa não há risco de descer muito rápido ee bater no poste ou sair para a rua que está bem próxima?
Poderíamos ficar um bom tempo listando falhas evidentes, e até outras não tão evidentes, mas eu gostaria de encerrar com algumas ações que poderiam ter sido executadas durante o planejamento e execução do projeto, mitigando ou até evitando estas falhas.
  1. Identifique todos os interessados, e converse com eles, levante as possíveis dificuldades do projeto e valide algumas opções com estas partes. Tente pensar como o usuário final do produto, se não conseguir, peça opinião ao usuário final.
  2. Identifique, gerencie e tome ações para mitigar os riscos do seu projeto. Antecipe possíveis riscos, não conte com a sorte ou com o controle de terceiros, controle você.
  3. Gerencie os custos do seu projeto, e pense também nos custos do produto. Será que foi economia fazer aquela rampa? E os benefícios futuros do produto, e a rejeição da população, e o marketing negativo, e a possibilidade de futuros acidentes? Tudo isso deve ser considerado no custo, não só do projeto, mas do ciclo de vida do produto como resultado do projeto.
É isso pessoal, espero que tenham gostado deste primeiro espisódio da séria "Cadê o gerente?". E eu termino perguntando: "Será que este projeto tinha um gerente definido?", e até mesmo "Será que todos os projetos deveriam ter a figura de um gerente?".

quinta-feira, 21 de abril de 2011

A Conferência - parte 5/5

Na última parte do evento, recebemos o brasileiro Alonso Mazini Soler, que palestrou sobre a Aplicação do método da corrente crítica, na corrida da São Silvestre 2010.

O estudo de caso demonstrado foi muito interessante, curioso e ainda conseguiu incentivar os participantes a pensarem na melhoria da qualidade de vida, e aplicarem o gerenciamento de projetos em áreas mais comuns do nosso cotidiano, e não só na vida profissional.

Alonso, sempre foi praticante de esportes como corrida e trekking, e resolveu no ano de 2010 participar da corrida de São Silvestre em São Paulo. Porém, não foi simplesmente para correr, decidiu montar uma equipe de projeto e trabalhar na aplicação do método de corrente crítica (CCPM - Critical Chain Project Management) para atingir o objetivo da prova de rua mais famosa do Brasil.

Eles montaram uma sala de controle nas proximidades da avenida paulista, com toda a infraestrutura necessária para manterem uma comunicação com o Alonso durante os treinos, e ainda transmitirem via internet os resultados obtidos durante o estudo.

Alonso frisou que o objetivo da corrente crítica é fazer com que se atinja o objetivo do cronograma estipulado, e se for possível antecipar o prazo estimado. E foi este o objetivo definido para o projeto da corrida.

O tempo estimado por eles, baseado nas experiências anteriores do Alonso, foi de 01h44m. No entanto, este prazo seria o caminho crítico, sem folgas ou pulmões. Ao aplicarem a CCPM, o prazo de conclusão da prova passou para 52m, com um pulmão também de 52m.

Após o planejamento, e as execuções das etapas de treino, inclusive com os testes de todos os equipamentos tecnológicos estipulados, o dia da prova foi um sucesso. Além de cumprir a corrida, Alonso conseguiu realizar a prova em 1h25m, 19 minutos abaixo do tempo inicialmente estimado, e ainda com uma reserva de pulmão.

Muitos podem dizer que foi questão de sorte, mas com certeza se analisarmos do ângulo de gerenciamento de projetos, podemos ver as aplicações que levaram a equipe a atingir os objetivos. Houve planejamentos, treinos, testes, e uma execução muito bem controlada, e toda a prova foi transmitida em tempo real para os seguidores do Alonso no Twitter, que até conseguiam sugerir estratégias, e estas chegavam aos ouvidos do Alonso via telefone celular. Então será que foi mesmo sorte, ou o resultado de um bom planejamento realizado e executado?

Mais informações sobre esta aplicação do método CCPM podem ser conseguidos no grupo chamado "Corre GP" na comunidade do Facebook. Eu já sou um dos seguidores.

Como mensagem final, Alonso nos deixou o seguinte recado: "O método CCPM não resolve todos os problemas, mas permite acompanhar e tomar as ações corretivas para manter o projeto dentro do prazo."

Saindo da corrente crítica, fomos ouvir Ricardo Triana, membro do corpo diretivo do PMI-USA, palestrar sobre a Obtenção de resultados empresariais através do gerenciamento de projetos.

Com um sotaque divertido, Ricardo que apesar de não ser brasileiro, usou um português fluente e de fácil entendimento para nos afirmar que o gerenciamento de projetos não é necessário quando não temos cobranças, quando temos dinheiro sobrando e sempre, e quando temos tempo a vontade para a execução do projeto.

Onde podemos encontrar este local? Foi a pergunta que todos fizeram, inclusive o próprio Ricardo, e aproveito para deixá-la aqui em aberto.

Além disso, Triano nos falou sobre alguns dos desafios do gerenciamento de projetos, onde eu destaco os seguintes:
  • Equilíbrio entre recursos e cronograma;
  • Globalização e equipes virtuais;
  • Inovações e mudanças constantes;
  • Responsabilidade social;
  • Alinhamento entre projetos e programas com a estratégia da organização.
Para finalizar, ele nos contou uma história que vou tentar reproduzir abaixo:

Um jardineiro foi ao seu jardim e plantou várias plantas diferentes. Ao retornar ao seu jardim algum tempo depois, viu que suas plantas estavam mortas, e se aproximando do pinheiro perguntou:
  • "Pinheiro, porque morreu?", e o pinheiro respondeu:
  • "Por que você me plantou um pinheiro, e não queria ser um pinheiro, eu sou muito grande, eu queria ser uma pequena rosa".
O jardineiro achou muito estranho, e se dirigiu até a rosa, chegando lá percebeu que a rosa também havia morrido, e ao perguntar porque a rosa morreu, obteve a seguinte resposta:
  • "Por que você me plantou uma pequena rosa, com espinhos, e eu não queria ser uma rosa, eu queria ser um grande e forte carvalho".
O jardineiro achou tudo mais estranho ainda, e foi até o grande carvalho, chegando lá viu que a grande árvore também havia morrido, e não se contentando perguntou por que ele havia morrido, e o carvalho o respondeu:
  • "Por que eu não queria ser um forte carvalho, sou muito grande e sem movimento, queria ser um delicado jasmim".
O jardineiro mais uma vez estranhou tudo isso e antes de perder a esperança foi até o seu jasmim, chegando lá viu que o jasmim estava vivo, bonito e alegre, ao lhe perguntar o porque de não ter morrido, a flor respondeu:
  • "Por que você me plantou como um jasmim, e eu adoro ser um jasmim e sou muito feliz."
Todos nós rimos da história, e até nos perguntamos rapidamente o porque da narração, e o Ricardo concluíu que não devemos tentar ser o que não somos, e não devemos querer transformar as pessoas ao nosso redor em quem elas não são. Cada um tem o seu papel, a sua função, e se todos estiverem onde realmente devem e querem estar, serão felizes e atingiram o sucesso.

Com a responsabilidade de encerrar o ciclo de palestras, a executiva Graça Foster da Petrobrás, nos falou um pouco sobre o funcionamento dos projetos na Petrobrás e os grandes desafios da empresa.

A Petrobrás está trabalhando em novos projetos com parceiras como a portuguesa Galp e a espanhola Repsol. Nos últimos 10 anos investiou um montante de $188 bilhões em projetos, e já tem planejado investir outros $224 bilhões de 2010 à 2014, sendo 53% destes projetos da área de exploração e produção, inclusive o pré-sal.

Graça afirmou que com um cenário destes, é completamente impossível realizar estes projetos sem a aplicação de um gerenciamento de projetos eficiente. Todos os projetos da empresa são integrados e estruturantes, não há projetos isolados e desconectados na companhia, e seguir metodologias e boas práticas são imprescindíveies e praticamente obrigatório entre os GPs da Petrobrás.

Um dado impressionante, foi que ela afirmou que não há nenhum projeto na Petrobrás com VPL negativo, e isso para quem gosta de evidências, significa sucesso nos projetos.

Ela também nos deu exemplos de boas práticas realizadas na Petrobrás, que com certeza contribuem para o sucesso dos projetos, sendo que destaco algumas abaixo:
  • O corpo diretivo é alinhado com os mesmos pensamentos, práticas e padrões, sendo este pensamento unificado um dos segredos para atingir o objetivo estratégico da empresa.
  • Verificação diária dos marcos dos principais projetos, onde existe um "paredão" que todos visualizam as escorregas de prazo, que ficam em vermelho destacado.
  • Comunicação vertical e horizontal, mantendo rapidez e objetividade, não tendo frescura de hierarquia.
  • As verificações e a captura de status das obras, são realizada in loco, ela praticamente não utiliza a sua sala para reuniões, as reuniões são todas realizadas no local de execução das obras.
  • Curva S é a companheira inseparável.
  • Não deve haver mais de um coordenador ("dono") de uma mesma tarefa, "se não vai dar água".
Além destas práticas, ela citou uma em especial, que garantiu fazer uma diferença muito grande nos projetos que ela coordena. Todos os responsáveis por tarefas na empresa, possuem além de nome e telefone, uma foto, pois todos possuem um rosto, e este rosto precisa ser conhecido e as conversas e decisões precisam ser olho no olho. Graça coordena 8.000 pessoas, e destes, afirma ela, não mais que 200 são desconhecidos para ela.

Graça fechou dizendo que um gerente de projeto precisa "ter o olho vermelho", o famoso "sangue no olho", não pode ter aquele olhinho branquinho, calmo e cansado. Então fica ai a dica para todos que almejam cargos expressivos em gerenciamento de projetos em empresas como a Petrobrás, tenha sangue no olho, ou como dizem os bons paulistas, "é sangue no zóio".

sexta-feira, 15 de abril de 2011

"Reunionite" no projeto BR101

Eu gostaria de comentar um pouco sobre um problema ainda existente no mundo dos projetos, as reuniões improdutivas e disfuncionais que acarretam em perda de tempo, desmotivação da equipe e consequentemente, no atraso de entregas e até mesmo do projeto todo.

Esta "doença" dos projetos é também conhecida como "reunionite", e apesar de ter sintomas clássicos e largamente difundidos, muitas vezes o diagnóstico é lento e incorreto.

No último dia 12 de abril foi diagnosticado um caso grave de "reunionite". Vários membros do governo do Estado de Santa Catarina, mais precisamente o governador do estado, três senadores, 15 deputados federais, 14 estaduais, além de alguns prefeitos e vereadores foram até Brasília para uma reunião com o governo federal para receberem as datas importantes (marcos) do projeto de duplicação da rodovia BR101.

Somente após o início da reunião, com toda a comissão citada já em Brasília, é que ficaram sabendo que o principal influenciador da reunião, o ministro dos transportes, não estaria presente, nem tão pouco os dirigentes das empresas que estão executando as obras.

Lembrando que todos os envolvidos foram deslocados com o objetivo único de ouvir o ministro dos transportes divulgar as datas dos marcos mais importantes do projeto, a reunião foi totalmente improdutiva, e nenhum dos participantes precisaria ter se deslocado até o local agendado.

Este é um exemplo claro da falta de planejamento e da ausência de objetividade de reuniões, que além de não gerar valor agregado nenhum ao projeto, ainda gera desperdício de dinheiro, agravado pelo deslocamento de vários recursos que poderiam estar executando outras tarefas produtivas para o projeto.

O recado que deixo é para que tenhamos mais cuidado com as reuniões. Procure planejar bem a pauta da reunião, confirme com uma certa antecedência o comparecimento das pessoas chaves, vá preparado para a reunião e se a reunião não for gerar o valor esperado cancela-a antes de seu início, evitando com isso aumentar e prolongar o problema.

Outra dica é para as reuniões mais frequentes, semanais por exemplo, deve-se ter mais atenção para dois momentos, o início que é quando ainda não entramos no tema da reunião e podemos ter atrasos na espera de todos os participantes, e no fim, quando prolongamos assuntos já encerrados ou entramos em temas que não deviam ser discutados na reunião originalmente agendada.

A reunião é uma arma forte para o sucesso do projeto, mas também pode gerar fracassos se não for bem conduzida.

domingo, 10 de abril de 2011

A Conferência - parte 4/5

O último dia de palestras foi iniciado pelo argentino Pablo Lledó, falando sobre o tema "Dicas para um líder ágil".

Pablo abordou principalmente a questão do tempo gasto nos projetos, e a influência de não se gerenciar corretamente este tempo, causando perdas nos trabalhos realizados e com frequência não gerando valor aos projetos, clientes e organizações.

Ele reforçou a existência de três tempos a serem considerados, vamos entendê-los:
  • Tempo do calendário
    • É o tempo que define as horas do dia, que todos conhecemos por conter 24 horas.
  • Tempo de trabalho
    • É o tempo que aplicamos ao trabalho, normalmente a maioria das empresas utiliza 8 horas de trabalho por dia.
  • Tempo de valor agregado
    • É o tempo que efetivamente geramos ganhos aos nossos clientes e aos nossos projetos, é o tempo que realmente produzimos algo em função do objetivo do projeto.
A análise destes três tempos resulta em uma das maiores preocupações atuais da maiora dos gerentes de projetos, o desperdício do tempo. Pablo observou que, de acordo com pesquisas recentes, de 8 horas trabalhadas por dia, apenas 2 horas geram valor aos projetos. É um número assustador não é?

Estes números foram retirados principalmente de observações que todos nós podemos realizar em nossos ambientes de trabalho. É só retirarmos aquelas horas em que estamos em reuniões improdutivas, telefones extensos demais fazendo o papel de psicólogos com nossos clientes, compromissos marcados para uma determinada hora que começa 15 ou 30 minutos depois, aquela "navegada" rápida no site de notícia, o café estendido para uma conversa descomprometida, e por ai vai. Se retirarmos isso tudo da conta, e apenas somarmos as horas produzindo valor agregado aos projetos com certeza vamos obter números impressionantes.

O mais importante é destacarmos que o maior tempo perdido é aquele que realmente não percebemos, e justamente se torna o mais difícil de evitar. Abaixo seguem os problemas que tiveram maior destaque na palestra:
  • O primeiro é a reunionite. Muito tempo é perdido em reuniões, no início ficamos esperando todos chegarem; durante, perdemos o foco, falamos de vários assuntos que não tinham a ver com a pauta da reunião, e muitas vezes nem sabíamos ao certo qual era a pauta da reunião; e no final, enrolamos para terminar e voltarmos a rotina.
  • O segunda é a falta de objetividade. Muitas pessoas não sabem ir direto ao ponto quando precisam, dão voltas, comentam diversas coisas e assuntos paralelos, e só depois de algum tempo entram no assunto realmente desejado, e isso gera desperdício de tempo. Temos que tentar ser mais objetivos no momento de passar e pedir informações.
Diante destes problemas com o tempo, Pablo focou em alguns princípios básicos baseados no pensamento Lean, para sugerir formas de ganharmos pelo menos 10 minutos a mais por dia, o que geraria ao final de uma semana, quase 1 hora a mais de valor agregado aos nossos projetos. Parece pouco, mas se você relembrar os números acima, verá que não é tão pouco assim.

Destaco alguns dos mandamentos Lean* de Paul Leido, que são bem semelhantes a outras leis ágeis.
  1. Realize reuniões diárias de 10 minutos, ao invés de 1 reunião semanal de 1 hora.
  2. Tenha cuidado com a reunionite.
  3. Não reinvente a gestão de projetos, use os padrões já existentes.
  4. O caminho crítico é importante, mas observe também a corrente crítica.
  5. Evitar o desgaste excessivo dos profissionais, aposte em melhorar a qualidade de vida da equipe.
* O pensamento Lean foca na remoção do desperdício, e tem várias similaridades com o Scrum.

Seguindo a agenda castelhana do evento, seguimos com a palestra da uruguaia Liliana Buchtik, que abordou como tema uma das ferramentas mais importantes no gerenciamento de projetos, e que ainda é negligenciada e muitas vezes abandonada pelos gerentes, a WBS (Work Breakdown Structure), também conhecida em português como EAP (Estrutura Analítica do Projeto).

Com este enfoque, ela afirmou que esta negligência ou abandono se dá ao fato dos próprios gerentes não saberem a real utilidade da WBS, e em outras vezes confundirem a aplicação desta ferramenta com a de outros documentos do projeto, e erroneamente concluirem que a WBS é desnecessária ou repetitiva.

Para ajudar a entender melhor a aplicação desta ferramenta, Buchtik reforçou que o principal conteúdo da WBS deve ser os deliverables, ou seja, as entregas do projeto. Para fixarmos ainda mais este princípio, devemos pensar sempre que a WBS deve conter as "coisas" que podemos ver, pegar e medir; podendo ser traduzido também em tudo que é tangível, mas nunca, nunca devemos colocar tarefas na WBS.

Colocar tarefas na WBS é uma das principais confusões aplicadas, mas há outras, e para evitarmos o uso incorreto da WBS devemos:
  • Não vincular tarefas e muito menos sequenciamento de tarefas na WBS;
  • Não confundir WBS com cronograma ou diagrama de redes, ambos sim devem ser utilizados para o vinculo e sequenciamento de tarefas, não a WBS;
  • Não confundir WBS com organograma organizacional;
  • Não confundir o que deve ser feito para entregar o projeto, com o como deve ser feito. O papel da WBS é mostrar somente o que deve ser feito, e não como deve ser feito.
Com o objetivo de estimular e provocar o uso da WBS, Buchtik falou sobre os benefícios desta ferramenta, eu vou destacar apenas alguns dos citados por ela, mas há vários outros.
  • Entender o trabalho precocemente;
  • Evitar mudanças sem controle;
  • Entregar o que se espera;
  • Visualizar o trabalho interno e externo (outsourcing);
  • Visualizar os limites do projeto e entender as complexidades;
  • Ajuda a melhorar a execução do projeto;
  • Ajuda a explicar melhor os trabalhos do projeto;
  • Fundamenta e serve de base para contratações;
  • Melhora a comunicação entre a equipe do projeto;
  • Melhora o alinhamento das expectativas com os stakeholders, melhorando também o atendimento as expectativas;
  • Melhora o controle e a medição dos trabalhos do projeto.
Antes de finalizar a palestra, Buchtik deixou algumas dicas importantes que podem ser aplicadas a WBS, tais como:
  • O dicionário da WBS não é obrigatório, mas deve ser feito quando necessário, por exemplo em projetos grandes ou totalmente novos para a empresa;
  • Vincular os pacotes de trabalho da WBS com o cronograma através de um identificador;
  • Os seguintes softwares podem ser usados para a construção da WBS:
    • WBS Chart Pro (um dos mais baratos);
    • Mind View (mais utilizado para mapa mentais, mas também é bem usado para WBS);
    • WBS Director;
    • WBS Modeler (funciona com o MS Visio e é gratuíto).
Por fim, recebemos um recado muito importante, que soou quase como uma ordem, para praticarmos a WBS, experimentarmos sempre esta ferramenta, e não somente como auxílio para venda, mas como auxílio para o planejamento e controle do projeto. Praticar, praticar e praticar sempre!

obs: Para conhecer mais sobre a WBS (EAP), clique aqui e visite o item Criar a EAP na sessão Planejamento 1 deste mesmo blog.