Arquivo

Archive for the ‘Ferramentas e técnicas’ Category

Turbine o gerenciamento de seus projetos com novas tecnologias

março 26, 2010 5 comentários

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

Jake

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

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

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

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

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

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

Simon

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

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

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

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

E VOCÊ?

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

Anúncios

Não subestime o poder de um “Kickoff”

março 22, 2010 3 comentários

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

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

Seja simples! Todos à sua volta agradecem!

“O projeto andou pra trás?”

julho 17, 2008 8 comentários

Já falei por aqui sobre possíveis contribuições que um software de gerenciamento de projetos pode trazer para o bom desempenho dos gerentes. Entretanto, alguns cuidados devem ser tomados em sua utilização, para que problemas e uma falsa sensação de controle sejam evitados. Software é apenas uma ferramenta e não é um atalho para capacitação de fato em gerenciamento de projetos. A história abaixo ilustra bem o que quero dizer.

Uma grande empresa de TI tinha em mãos um dos mais desafiadores projetos de sua existência. A substituição da tecnologia básica (hardware e software) que suportava a maioria das soluções oferecidas aos seus maiores clientes. Dada a criticidade da iniciativa, o presidente assumiu pessoalmente o papel de sponsor. Após alguns meses em que o projeto parecia não caminhar muito, deliberou que todas as reuniões gerenciais (que ocorriam mensalmente com todos os representantes funcionais da organização – gerentes, superintendentes e diretores), teriam em sua pauta uma apresentação breve e objetiva do projeto. Para garantir tal objetividade optou-se, entre outras coisas, pelo uso de um indicador de progresso – o % de conclusão.

Primeira reunião e o indicador foi apresentado: “Concluímos 13% do projeto!” – disse o gerente.

Segunda reunião e as coisas pareciam caminhar bem: “O percentual de conclusão atual do projeto é 25%” – anunciou novamente o gerente. Doze por cento em um mês é significativo, para algo que todos sabiam ser demasiado complexo.

Terceira reunião e o ritmo parecia ter diminuído: “Avançamos pouco desta vez presidente: estamos com 27% concluído”. A explicação que se seguiu, na tentativa de justificar as diferenças de desempenho entre os dois meses não parecia muito convincente . Mas a reunião terminou sem maiores percalços.

Na quarta reunião algo muito estranho aconteceu. Após uma explicação um pouco mais longa sobre o andamento do projeto veio a afirmação, no mínimo curiosa: “… e nosso percentual de conclusão é de 26%.”

O sponsor do projeto, incrédulo, disparou: “Deixe-me ver se entendi direito. O projeto andou pra trás?”

Evidentemente, as explicações dadas pelo gerente ao sponsor para o retrocesso do projeto não foram aceitas. Uma delas foi um possível aumento do escopo do projeto. Mas como o escopo foi aumentado sem que o sponsor tomasse conhecimento? Se este fosse o único motivo, já teríamos um problema na abordagem de gestão utilizada. Mas não era. O fato é que o % de conclusão do projeto era dado pelas contas realizadas pelo software Microsoft Project. Entretanto o software tem uma lógica para o cálculo desse percentual. E o padrão de atualização do cronograma (seja na atualização do progresso individual das atividades, seja no refinamento/desmembramento das atividades) deve ser feito segundo determinadas diretrizes, compatíveis com esta lógica, para que os resultados dos cálculos sejam confiáveis. Não basta simplesmente lançar um conjunto de números e copiar o % global apresentado para a apresentação do Powerpoint a ser mostrada na reunião de status. Parece que isso não foi muito bem observado.

Um cronograma, com suas datas de início e fim, recursos alocados e percentuais de conclusão individuais de cada tarefa é apenas um modelo da realidade. Os resultados apresentados serão tão bons quanto for a modelagem realizada. É muito importante saber o que se está fazendo. De outra forma o gerente de projeto pode passar por situações no mínimo constrangedoras, como a descrita acima.

Softwares de GP: o que estimula as pessoas a utilizar?

julho 4, 2008 2 comentários

 

O que leva um profissional a usar de forma efetiva um software em seu ambiente de trabalho? A resposta a esta pergunta vale ouro, pelo menos para dois grupos de pessoas: (1) Produtores de software (2) Patrocinadores de compras de software. Uso de fato de um produto é garantia de lucros para quem o produz e sinal de dinheiro bem gasto para quem paga a conta.

O tema é tão importante que teve gente gastando tempo para realizar um estudo científico a fim de entender os fatores que de certa forma poderiam afetar a aceitação e/ou uso de softwares de gerenciamento de projetos por seus usuários. Os resultados estão publicados no mesmo estudo que citei no artigo anterior (“Impact of Organizational and Project Factors on Acceptance and Usage of Project Management Software and Perceived Project Success”, publicado na edição de junho de 2008 do Project Management Journal). Vou comentá-los brevemente a seguir. Convido os interessados em maiores detalhes a lerem o artigo na íntegra.

Vamos então aos resultados. Os pesquisadores chegaram à conclusão de que os fatores mais importantes, pela ordem, dentre aqueles escolhidos a priori com base em estudos anteriores, são:

1. Qualidade da informação fornecida pelo software
2. Complexidade do projeto sendo gerenciado
3. Funcionalidades disponíveis
4. Facilidade de uso

Um pouco mais abaixo ainda apareceram: experiência do usuário com softwares de gerenciamento de projetos e formação do usuário.

De forma contrária ao esperado, nivel de treinamento na ferramenta não apresentou correlação estatisticamente significante com nível de uso.

Analisando de forma bem prática, é interessante observar que os usuários parecem estar muito interessados na qualidade da informação disponibilizada pelo software (leia-se acurácia e facilidade de entendimento). Aspectos que normalmente imaginamos serem relevantes como facilidade de uso e funcionalidades disponíveis são também importantes, mas não tanto quanto o primeiro.  O mais interessante, entretanto, foi a constatação de que treinamento em demasia não resolve o problema da utilização. Ou seja, mais vale a experiência do usuário na utilização de ferramentas similares. Na prática não creio que isto queira dizer que treinamentos são inúteis. Eles são apenas insuficientes. Servem para fornecer um conjunto fundamental de conhecimentos. Mas parece que, para aprender, aprender mesmo, só fazendo. Já ouviram isto antes?

Softwares de GP e o desempenho dos gerentes

julho 2, 2008 6 comentários

 

Uma discussão recorrente em organizações que começam a adotar boas prática de gerenciamento de projetos é: devo investir meu dinheiro em um software de gerenciamento de projetos? Quem trabalha com implementações de PMOs, projetos de melhoria com base em modelos de referência (CMMI, MPS.Br, OPM3, MMGP) e iniciativas afins sabe que o software não é o fator mais importante para o sucesso deste tipo de empreendimento. Apoio da alta direção e boa formação dos colaboradores na área de GP, por exemplo, são aspectos que costumam aparecer como mais relevantes.  Entretanto, a adoção de ferramentas específicas para GP tais como MSProject, Primavera e NetProject, pode contribuir bastante para o bom desempenho dos gerentes de projeto de uma organização.

 

Pelo menos é o que pode se deduzir a partir dos resultados publicados no artigo “Impact of Organizational and Project Factors on Acceptance and Usage of Project Management Software and Perceived Project Success“, publicado na edição de junho de 2008 do Project Management Journal. O estudo que lhe deu origem comprovou estatisticamente a validade de uma série de hipóteses, entre elas a que transcrevo a seguir:

H10: O uso de um software de gerenciamento de projetos tem um relacionamento positivo com o desempenho dos gerentes de projetos, percebidos por eles próprios.

Nesse caso específico, portanto, utilizou-se a opinião dos próprios gerentes de projeto para se chegar a conclusão de que há uma correlação entre o desempenho do profissional e uso de uma ferramenta específica. O estudo contou com a participação de 497 pessoas.

De fato a utilização de um software adequado à realidade da organização pode ajudar bastante. Tarefas como a criação de diagramas de rede e cálculos de índices de desepenho do projeto (tais como CPI e SPI) são muito simplificadas quando se tem uma boa ferramenta de apoio. Além disto, boa parte dos softwares atualmente tem seus dados armazenados em bancos de dados corporativos (e não em arquivos isolados nas máquinas dos usuários) possibilitando um melhor aproveitamento das informações históricas dos projetos, algo fundamental para o aumento gradual da maturidade em GP de qualquer organização.

O estudo, que pode ser acessado gratuitamente por filiados ao PMI no site da instituição,  trouxe também outras conclusões interessantes. Já que a adoção de um software é vista com bons olhos pelos gerentes de projetos, o que leva estas pessoas a utilizarem mais ou menos estas ferramentas? Nove outras hipóteses foram testadas para responder a esta pergunta. Falo delas no próximo artigo. Até lá!

Crashing na China

junho 27, 2008 3 comentários

 

Não, não, não… Apesar da similaridade de nomes (crash x crashing), não estou falando da quebra de nenhuma bolsa de valores na China. Crashing é apenas e tão somente uma técnica de compressão de cronograma (assim como o Fast Tracking tratado em um post anterior) que resolvi ilustrar utilizando como exemplo o pujante desenvolvimento chinês. Vejam o trecho abaixo, extraído da Revista Exame, edição do dia 18/06/2008 (a reportagem completa pode ser lida aqui): 

“Os chineses colocam simplesmente o número de pessoas que precisam para acabar as obras rápido”, diz Pol-Henry Cox, presidente da consultoria imobiliária Jones Lang LaSalle em Xangai. “Eles usam até dez vezes mais gente numa obra do que europeus e americanos.”

O crashing visa diminuir o tempo de um projeto por meio da análise de diversas alternativas, a fim de determinar como obter a máxima compressão da duração do cronograma pelo menor custo adicional. Ou seja, normalmente paga-se mais para se obter os resultados de um projeto em um prazo menor. O objetivo é gastar o mínimo necessário para conseguir tal benefício.

 

Foto aérea do aeroporto de Pequim

Foto aérea do aeroporto de Pequim

Os empreendedores chineses parecem ter conseguido utilizar bem esta técnica se olharmos a questão do ponto de vista estritamente financeiro. Com mão de obra farta e barata associada ao poder ditatorial do governo chinês, não é difícil avançar mais rapidamente sem gastar muito mais. Entretanto, olhando a questão de forma mais ampla, percebe-se que, se o custo financeiro é pequeno, o mesmo não pode-se dizer do socio-ambiental. Algumas outras informações extraídas da reportagem deixam isto muito claro:

Problemas sociais:

–  É comum que os operários só recebam ao final da obra (o que é contra a lei), uma forma de remuneração que estimula a execução do trabalho o mais rápido possível.

–  Ao fim da construção, hora em que os operários estão exaustos e prestes a perder seu teto, podem receber a seguinte oferta: ou aceitam um pagamento menor que o combinado e trabalham na próxima obra ou estão demitidos — sem salário, emprego ou casa. Uma pesquisa da universidade Tsinghua mostrou que somente 31% dos operários da construção civil recebem seu salário inteiro.

– Segundo um estudo recente, mais de 60% das construções na China envolveram a tomada irregular da propriedade alheia. De acordo com a Universidade de Michigan, apenas um de cada cinco desapropriados é consultado sobre a quantia a ser paga. Quem não aceita o montante oferecido pelos empreiteiros corre o risco de não receber nada.

Problemas ambientais: 

– A China tem 16 das 20 cidades mais poluídas do mundo

– Metade da água dos rios chineses é imprestável

– 750 000 chineses morrem todos os anos em decorrência da poluição

– O país perde entre 3%e 7%de sua produção por ano devido a doenças causadas pela poluição

 

Os resultados chineses são impressionantes. Não há dúvidas quanto a isso. O número de quilômetros em auto-estradas saltou de 147 em 1989 para 45600 ano passado. Cem aeroportos foram construídos desde 1993. Isso pra ficar só em dois exemplos. Porém, o custo desse desenvolvimento todo, aparentemente baixo, mostra-se uma conta cara a ser paga, seja pela classe baixa chinesa, seja pelas próximas gerações que enfrentarão problemas ambientais terríveis, se nada diferente for feito. Um exemplo claro de como análises superficiais podem confundir alguns gerentes de projeto mundo afora.

 

Fast Tracking arrojado

junho 13, 2008 3 comentários

“A velocidade é uma questão importante. É preciso ir muito mais rápido do que no passado, porque outras empresas conseguem copiar os produtos rapidamente. Não corremos risco com segurança, mas corremos algum risco com o dinheiro. Em certos casos, começamos a erguer a fábrica para produção em grande quantidade de um produto ao mesmo tempo em que estamos criando seu protótipo. Sabemos que depois será necessário alterar a planta, mas não podemos esperar fazer tudo em seqüência” . Chad Holliday, presidente mundial da Dupont

“Paralelismo / Fast Tracking [Técnica]. Uma técnica de compressão do cronograma de um projeto específico que altera a lógica de rede para sobrepor fases que normalmente seriam realizadas em seqüência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo. ” PMBOK Terceira Edição

Prática e teoria. Chad Holliday, presidente mundial da Dupont em entrevista à revista Época Negócios, fala sobre a influência da velocidade crescente dos negócios nos processos de inovação. Sem querer trata da implementação de um conceito conhecido para os profissionais da área de gerenciamento de projetos: o paralelismo ou fast tracking.

Ok, já estávamos acostumados a paralelizar atividades que pelo bom senso deveriam ser seqüenciais. Afinal todo e qualquer projeto é pra ontem não é mesmo? Mas construir uma fábrica para produção de algo que ainda não se sabe o que é? É, nosso mundo está realmente dinâmico e tempo é, cada vez mais, igual a dinheiro.

 

 

 

Entretanto, antes de achar que seu cronograma sempre deve ser comprimido por meio do paralelismo, pare e pense. Tanto na teoria quanto na prática a mensagem é clara: este tipo de abordagem traz riscos para qualquer projeto. A DuPont conhece bem os seus riscos e topa corrê-los por uma necessidade inerente à sua sobrevivência: inovar sempre e rápido, muito rápido. Você conhece os seus? Sabe quanto eles podem custar? Sabe qual o benefício de bancá-los? Projetos são únicos e qualquer decisão deve levar em conta suas características peculiares.