Estudo de Benchmarking mostra avanço de GP nas organizações

Com algum atraso (afinal o relatório foi publicado há alguns meses) reservei um tempo para a leitura do Estudo de Benchmarking em Gerenciamento de Projetos Brasil 2007 . Trata-se de um belíssimo trabalho realizado conjuntamente pelas diversas seções regionais brasileiras do PMI, com o objetivo de traçar um panorama do gerenciamento de projetos em nosso país. Um total de 185 organizações de 13 diferentes setores de atuação participaram do estudo, respondendo ao questionário proposto. Esta iniciativa vem sendo executada anualmente desde 2003, a princípio como uma iniciativa local da seção do PMI-Rio. Dado a relevância do conteúdo apresentado, resolvi escrever sobre ele, mesmo não tendo sido publicado nos últimos dias.

São muitas as informações apresentadas, mas sinteticamente pode-se dizer que a principal conclusão a que se pode chegar é a de uma maior penetração do gerenciamento de projetos nas organizações brasileiras em relação a anos anteriores. Selecionei alguns dados que corroboram esta afirmação. Vejam:

- Em 2006, 20% das organizações relataram algum nível de resistência interna importante em relação ao Gerenciamento de Projetos. Este número caiu para 17% em 2007.

- Caiu de 40% para 30% o número de organizações que afirmaram não possuir um escritório de gerenciamento de projetos.

- Em relação a metodologias, 91% das organizações disseram possuir alguma em 2007, contra 84% em 2006. A utilização de fato da metodologia continua sendo um problema, mas com proporções menores no último levantamento: 40% das organizações disseram utilizá-la sempre, em qualquer projeto. Em 2006 o percentual que disse o mesmo foi de 30%.

- Por fim, em 2007, 91% das organizações possuíam ou pretendiam desenvolver programas de capacitação em GP para seus funcionários. Em 2006 o número era 86%.

Outro ponto interessante no trabalho foi o que trata da funções desempenhadas nos PMOs das organizações entrevistadas. Alguns resultados foram totalmente compatíveis com o estudo encomendado pelo PMI Internacional em 2005 (The Multi-Project PMO: A Global Analysis of the Current State of Practice), comentado por mim em um artigo anterior. Das 5 funções consideradas mais importantes / mais executadas pelas organizações nos dois estudos, três são coincidentes ou praticamente idênticas. Veja (o termo antes da barra refere-se ao estudo internacional e o depois refere-se ao estudo brasileiro):

- Reportar status do projeto para a alta direção / Fornecer informação consolidada dos projetos para a Alta Administração

- Desenvolver e implementar uma metodologia padrão / Definição e suporte à metodologia de Gerenciamento de Projetos

- Desenvolver competências dos funcionários, incluindo treinamento / Treinamento em Gerenciamento de Projetos

ATITUDE: o diferencial dos gerentes de projeto que se destacam.

Ok, você já tem vastos conhecimentos sobre gerenciamento de projetos. Estudou o PMBOK, alguns outros livros de referência, aprendeu o que é uma WBS, como desenvolver um cronograma, a importância do gerenciamento de riscos… Tem um título de especialista em gerenciamento de projetos. Conseguiu aquela tão desejada contratação para uma posição como GP. Então, como num terrível pesadelo, coisas estranhas começam a acontecer.

Projeto vendido, escopo mal definido, tipo de contrato escolhido de forma inadequada (ah, se mais gente soubesse que contratos de preço fixo não são a única opção!), mudanças chegando a todo momento de forma desordenada e você foi o escolhido pra coordenar tudo isto. Ao tentar argumentar contra o caos instalado, as pessoas parecem não querer ouvi-lo. Você resignado, entrega os pontos e deixa o barco ir conforme a maré. Cada dia é um suplício. Sua família e seus amigos não conseguem mais ouvir você reclamar de sua empresa. Algo parece errado, não?

Bem vindo ao mundo real! Algumas empresas já possuem um certo grau de maturidade, tornando a vida de seus gerentes bem mais feliz. Mas pra boa parte delas, boas práticas de gerenciamento de projetos são um conjunto de novidades ao mesmo tempo interessantes e muito difíceis de implementar. Mesmo com todos os seus conhecimentos, sua vida será normalmente muito difícil se lhe faltar um outro componente: ATITUDE!

 

Muitas empresas agem errado, não porque querem. Agem assim simplesmente porque não sabem como fazer o certo. Nesse caso, VOCÊ pode ser o agente da mudança, desde que esteja disposto a se dedicar um pouco mais.

Mesmo querendo acertar, uma organização não muda facilmente. A inércia, descrita precisamente nos livros de física, age praticamente da mesma forma nas relações humanas e de negócios. Pra conseguir aplicar as boas práticas de gerenciamento de projetos será preciso despender boa dose de energia convencendo seus pares, chefes e subordinados. Não adianta dizer “eu sei que o certo é assim e você está errado”. É preciso mostrar, com exemplos e resultados palpáveis os seus pontos de vista. Capacidade de se comunicar, negociar e se relacionar serão de enorme valia nesse emprendimento. E a ATITUDE pra colocar tudo isto em prática é fundamental.

Tudo bem, há também aquelas organizações que parecem estar fadadas a padecer no fogo do inferno pra sempre, negando-se a mudar quando esta é a única opção plausível. Nesse caso não tem muito jeito. A melhor opção é normalmente cair fora. Mas concentre-se nos casos em que há como mudar o panorama geral. Você pode pensar: “Tudo isto é muito difícil, não compensa”. Concordo com a primeira parte da frase, mas não com a segunda. Ser um agente de mudanças não é tarefa fácil. Mas os resultados são, de modo geral, bastante recompensadores. E diferenciam você da multidão!

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.

 

Peraí! Eu posso “pular” um processo do PMBOK?

Aula de gerenciamento de riscos em um curso de especialização em gerenciamento de projetos. Levei alguns exercícios de múltipla escolha para gerar discussão nos conceitos e técnicas apresentados até então. Em um deles, surgiu um debate interessante. A questão era a seguinte:

Você está planejando um projeto que na concepção de todos apresenta risco muito baixo. O projeto terá uma duração de 5 meses, está sendo realizado pela sua própria empresa e tem baixa prioridade. Baseado nestas informações, o que é melhor fazer?

a) Pular a análise quantitativa de riscos.
b) Gastar apenas um dia com gerenciamento de riscos.
c) Começar planejamento de resposta a riscos somente com as pessoas mais participativas.
d) Gastar a mesma quantidade de tempo gasta em outros projetos no gerenciamento de riscos, já que pode haver riscos não identificados.

Após o anúncio de que a resposta certa era a letra a, uma reação interessante ocorreu. Veio a pergunta:

- Peraí! Eu posso “pular” um processo do PMBOK? Não imaginei que isso fosse permitido.

 

 

Confesso que gostei bastante do questionamento, pois me permitiu explorar um ponto importante com a turma e agora com vocês.  Esta dúvida esta na base de algumas das confusões envolvendo o PMBOK que tenho presenciado com grande freqüência. Muitos ainda o encaram como uma metodologia a ser seguida e não como um corpo de conhecimento. Um corpo de conhecimento traz boas práticas e não é prescritivo. Vejam o parágrafo abaixo, extraído do próprio PMBOK:

 O principal objetivo do Guia PMBOK® é identificar o subconjunto do Conjunto de conhecimentos em gerenciamento de projetos que é amplamente reconhecido como boa prática. “Identificar” significa fornecer uma visão geral, e não uma descrição completa. “Amplamente reconhecido” significa que o conhecimento e as práticas descritas são aplicáveis à maioria dos projetos na maior parte do tempo, e que existe um consenso geral em relação ao seu valor e sua utilidade. “Boa prática” significa que existe acordo geral de que a aplicação correta dessas habilidades, ferramentas e técnicas podem aumentar as chances de sucesso em uma ampla série de projetos diferentes. Uma boa prática não significa que o conhecimento descrito deverá ser sempre aplicado uniformemente em todos os projetos; a equipe de gerenciamento de projetos é responsável por determinar o que é adequado para um projeto específico.

Portanto fica aí o recado: o PMBOK  deve  ser encarado como uma fonte de inspiração e não como regra absoluta. A frase parece poética, romântica demais, mas é a mais pura verdade. O discernimento da equipe de gerenciamento de projetos é fundamental para saber escolher, para cada situação específica, aquilo que deve ou não ser aplicado. Projetos são únicos, estão lembrados?

Mas afinal, o que faz um PMO (Parte 2)?

No artigo anterior mencionei que em um estudo encomendado pelo PMI foram identificadas 27 funções normalmente executadas por PMOs.  Os participantes da pesquisa foram solicitados a graduar a importância que cada uma das funções tinha para o seu PMO, em uma escala que variava de 1 (sem importância) a 5 (muito importante). A tabela a seguir mostra o percentual de PMOs em que cada função foi pontuada com 4  (importância considerável) ou 5  (muito importante): 

Função do PMO	% de PMOs onde função é importante
Reportar status do projeto para a alta direção	83%
Desenvolver e implementar uma metodologia padrão	76%
Monitorar e controlar o desempenho do projeto	65%
Desenvolver competências dos funcionários, incluindo treinamento	65%
Implementar e manter um sistema de informações de projetos	60%
Prover aconselhamento à alta direção	60%
Coordenação entre projetos	59%
Desenvolver e manter um scoreboard de projetos	58%
Promover o gerenciamento de projetos na organização	55%
Monitorar e controlar o desempenho do PMO	50%
Participar do planejamento estratégico	49%
Prover mentoring para gerentes de projeto	49%
Gerenciar um ou mais portifólios	49%
Identificar, selecionar e priorizar novos projetos	48%
Gerenciar arquivos de documentação dos projetos	48%
Gerenciar um ou mais programas	48%
Conduzir auditorias nos projetos	45%
Gerenciar interfaces com clientes	45%
Prover um conjunto de ferramentas sem preocupação com padronização	42%
Executar tarefas especializadas para os gerentes de projeto	42%
Alocar recursos entre projetos	40%
Conduzir revisões pós-projetos	38%
Implementar e gerenciar um banco de dados de lições aprendidas	34%
Implementar e gerenciar um banco de dados de riscos	29%
Gerenciar benefícios	28%
Conduzir networking and environmental scanning*	25%
Recrutar, selecionar, avaliar e determiner salários para gerentes de projeto	22%

* Veja a definição de environmental scanning na Wikipédia aqui. 

Vou me ater a uma análise mais aprofundada das quatro funções mais votadas, a fim de não tornar este artigo muito extenso.

A função que mais vezes apareceu como importante (Reportar status dos projetos para a alta direção) retrata uma preocupação sempre presente na cabeça dos executivos de escalões mais altos: a necessidade de informações precisas, objetivas e de fácil entendimento sobre os projetos . O PMO, neste caso, tem a função de filtrar, dentre todas as informações existentes sobre os projetos, aquelas que realmente importam para os tomadores de decisão. O uso de indicadores numéricos é fundamental neste processo. Esta função está estritamente ligada à terceira mais votada – Monitorar e controlar o desempenho do projeto -, já que é preciso estar a par dos projetos para que se possa reportar qualquer tipo de informação sobre eles. Outras funções associadas  são: “Implementar e manter um sistema de informações de projetos” e “Desenvolver e manter um scoreboard de projetos”.

A segunda  e quarta opções mais  votadas (“Desenvolver e implementar uma metodologia padrão” e  “Desenvolver competências dos funcionários, incluindo treinamentos”, respectivamente)  confirmam o que muito frequentemente vemos na prática: a visualização do PMO como um centro de excelência, responsável por definir como o gerenciamento de projetos deve ser tratado nas organizações e por capacitar os demais funcionários a seguir tais definições. Estas funções são constantemente executadas em PMOs pelo baixo nível de resistência encontrado, quando comparadas com a primeira e terceira por exemplo. São funções de suporte, que se bem executadas são vistas como um auxílio para os gerentes de projeto e não como ameaça. Por este motivo é bastante comum que tais funções sejam as primeiras a serem implementadas em muitos PMOs. Outras opções menos votadas, mas que guardam correlação com a segunda e a quarta pela sua natureza são: “Promover o gerenciamento de projetos na organização”, “Prover mentoring para os gerentes de projeto”  e “Prover um conjunto de ferramentas sem preocupação com padronização”.

Um fato que pode causar estranheza é a não aparição na lista acima de uma função relacionada  ao gerenciamento de um projeto diretamente. O motivo é simples: esta opção foi deliberadamente excluída pelos coordenadores da pesquisa e tratada de uma outra forma. Sua execução em PMOs foi medida em função do percentual de gerentes de projeto subordinados ao PMO diretamente. Veja os resultados no gráfico abaixo:

 

O gráfico mostra que não há exatamente uma tendência.  Entretanto  é interessante observar que boa parte das organizações (60% aproximadamente) são “8 ou 80″. Ou todos os gerentes de projetos estão ligados ao PMO ou nenhum deles está. Sem meio termo!

Mas afinal, o que faz um PMO (Parte 1)?

Há algum tempo atrás, estive presente em uma organização  em que era comum ouvir a seguinte afirmação:

“Nossa área de projetos deveria atuar como um PMO (Project Management Office, ou Escritório de Gerenciamento de Projetos). Como hoje ela é responsável por gerenciar diretamente os projetos, sobra muito pouco tempo para disseminar a cultura de GP na empresa.”

A alegação de quem fazia este tipo de afirmação era legítima. De fato a área de projetos gastava praticamente todo o seu tempo gerando propostas para novos projetos e gerenciando os já existentes.  Entretanto é interessante perceber que há um pressuposto implícito na colocação, de que um PMO deveria se preocupar fundamentalmente com a disseminação do gerenciamento de projetos na empresa e não com a execução dos projetos diretamente.  O problema na afirmação é, portanto, conceitual, já que não há um consenso sobre um conjunto único de funções a serem executadas por um PMO. O espectro de papéis a serem cumpridos por um PMO é bastante extenso e varia de empresa para empresa em função, predominantemente, de características internas e específicas de cada organização, tais como estratégia, processos, estrutura e cultura.

Esta foi uma das interessantíssimas descobertas presentes em um estudo encomendado pelo PMI e executado no ano de 2005, que teve como resultado o relatório: The Multi-Project PMO: A Global Analysis of the Current State of Practice. O estudo levou em consideração informações fornecidas por 500 PMOs ao redor do mundo, predominantemente localizados nos EUA, Canadá e Europa.

Abaixo são listadas algumas conclusões presentes no relatório: 

• Foram identificadas 27 funções executadas pelos PMOs presentes na amostra. Isto não quer dizer que todos os PMOs desempenhem todas as funções. 27 é o número total.
• Não há correlação entre o bom desempenho de um PMO e um subgrupo específico de funções executadas. Ou seja, um PMO pode ter bom desempenho realizando funções mais executivas ou funções de suporte. Tudo depende do contexto em que ele está inserido. 
• Não há variação sistemática nas características de PMOs em função do setor econômico, região geográfica e tamanho da organizações em que estão inseridos e nem em relação ao fato de tais organizações serem públicas ou privadas. As variações dentro destes grandes grupos são maiores do que as variações entre os grupos. Ou seja, o que determina de fato o perfil de um PMO são características mais internas da organização, tais como as já citadas estratégia, processos, estrutura e cultura.
• A implementação de um PMO dura um período que varia normalmente de 6 a 24 meses.
• A maioria dos PMOs tem um staff  reduzido.
• Expertise das pessoas que nele atuam é fundamental para o bom desempenho de um PMO.
• Algumas característica fazem com que o PMO passe a percepção de ser caro e inútil. Exemplos destas caracterítisticas: falta de expertise e controle exagerado.

 O estudo foi concluído no final de 2005, o que pode suscitar a idéia de desatualização, já que tudo tem evoluído muito rápido nos últimos tempos. Mas não creio que seja o caso. PMOs continuam sendo criados com objetivos distintos até hoje e não há uma receita de bolo sobre o que deve ou não estar contido nas atribuições de cada um deles. É fundamental pensar sobre quais os são pontos fundamentais a atacar. Esse é o ponto de partida. Melhorias e expansões na área de atuação vêm com o tempo.

No próximo post vou explorar melhor as 27 funções identificadas no estudo. Até lá!

 

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.