“O projeto andou pra trás?”

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?

 

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

 

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

 

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

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

“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.