Quão único é um projeto?

Um projeto, por definição, cria um produto, serviço ou resultado único, exclusivo. Mas quão único é este resultado? Já parou pra pensar a respeito?

Se nunca fez isso, aproveitemos o momento pra refletir um pouco.

Situação A: Suponha que você trabalhe em uma instituição de alta tecnologia e receba a incumbência de gerenciar um projeto de criação de um sistema imunológico artificial, que será posteriormente utilizado em chips tolerantes a falhas (antes de me chamar de louco saiba que tem gente por aí tentando produzir algo nesta linha). Inovação da pesada hein? Provavelmente ninguém nunca fez isso antes e quem teve a idéia de levar a iniciativa adiante provavelmente não sabe exatamente como chegar lá. O processo de criação de um produto desta natureza está longe de ser prescritivo. Ao contrário é provavelmente altamente empírico, o que quer dizer que algumas tentativas e erros podem e devem acontecer pelo caminho.

Situação B: Você agora é um gerente de projetos de uma empresa de infra-estrutura de TI convencional. Já implementou dezenas de redes de computadores em escritórios deste “Brasilzão” afora e acaba de ser nomeado GP para um nova inciativa do gênero. O passo a passo pra resolver a demanda do cliente é bem conhecido. Você tem documentado um processo de implementação de redes que, tirando algumas coisas que sempre variam caso a caso, funciona bastante bem de modo geral.

Situação A e Situação B podem ser tratadas como projetos, certo? No caso da Situação A creio não haver muita dúvida. Em B, é bom lembrar àqueles que ainda não estão muito seguros que “algumas coisas sempre variam caso a caso” e que “Deus está nos detalhes” – esta última frase não sei exatamente de quem é mas sempre gostei dela e acho que se encaixa bem aqui.

Dado que consegui convencê-los que ambas as demandas podem ser consideradas projetos (se alguém ainda não se convenceu comente o post logo abaixo dizendo porque ), podemos afirmar também que as duas devem ser planejadas, monitoradas e controladas. Mas será que devemos planejá-las, monitorá-las e controlá-las da mesma forma? Veja a figura abaixo. Ela nos ajuda a clarear um pouco a situação:

Veja que a demanda B pode ser classificada como projeto, mas situa-se próximo ao que costumamos chamar de “Operações Continuadas”, para classificar aquilo que é repetitivo. Já a demanda A está muito próxima do outro extremo do desenho. Denominei esta outra extremidade de “Mundo Completamente Desconhecido”, mostrando que, quando mais para direita, mais nebuloso e indefinido é o resultado que se espera do projeto. O ponto “Marco zero de projetos” é conceitual e serve apenas para mostrar que a partir de algum momento, algo deixa de ser repetível e contínuo para se tornar temporário e exclusivo.

Algumas conclusões interessantes podem ser tiradas deste desenho:

• A primeira é que a distinção entre operações continuadas e projetos não é discreta, mas contínua. Existem operações continuadas muito padronizadas (ex: produção de tijolos), operações continuada menos padronizadas (ex: manutenções de software não projetizadas), projetos com produtos finais pouco exclusivos (situação B) e projetos com produtos finais muito exclusivos (situação A);
• E a segunda, retornando à nossa dúvida que ficou em aberto é: apesar de A e B serem considerados projetos, tratam-se de duas demandas com perfis bastante diferentes. Assim a abordagem gerencial para conduzir as duas iniciativas será, naturalmente diferente.

Em B as entregas, tanto finais como intermediárias, podem ser delineadas com boa precisão. Afinal de contas isso já foi feito dezenas de outras vezes. É possível definir, seqüenciar e estimar recursos e durações com boa taxa de acerto para uma quantidade razoável de atividades, até mesmo para algumas próximas do final do ciclo de vida do projeto. Ou seja, enxergamos com clareza todo o fluxo de atividades a ser desenvolvido, do início ao fim do projeto.

Em A as coisas já são mais complicadas. Tem-se uma idéia do que se quer ao fim do projeto, mas é impossível definir-se logo no primeiro ciclo de planejamento, de forma prescritiva, a seqüência de todas atividades a serem executadas para chegar-se ao produto final. Produtos intermediários são gerados e seus resultados são analisados para se definir etapas posteriores e em alguns casos para se decidir se o projeto segue ou não adiante. É possível planejar, monitorar e controlar mas a filosofia é outra. O produto final é mais ou menos conhecido. Há objetivos traçados. Mas o caminho que é percorrido é definido ao longo do projeto. Planejado sim, mas com antecedência menor.

De forma bem pragmática, executar um projeto como o descrito em B é parecido com viajarmos para o Nordeste comprando um pacote turístico. Sabemos que vamos conhecer 5 cidades, os hotéis em que vamos nos hospedar, os passeios que vamos fazer (inclusive com os horários). Sempre tem algum imprevisto, mas de modo geral a coisa não muda muito. Executar A é mais ou menos como viajar para o Nordeste por conta própria com o hotel para o primeiro destino reservado e um objetivo de conhecer outras 4 cidades. Que outras 4? Ainda não sabemos, mas quando estivermos prestes a sair da primeira já teremos reservado o hotel para a segunda, tendo inclusive uma boa idéia de quando iremos para a terceira. Alguém poderia me dizer: o bom mesmo é pegar o carro e ir viajando sem destino certo… Parando quando der vontade, conhecendo praias nunca antes visitadas, decidindo tudo na última hora, sem plano algum. Eu diria que um comportamento assim pode até funcionar… pra sua próxima viagem para o Nordeste. Mas nunca para a criação de um sistema imunológico artificial. Entendeu a diferença?

Você conhece a força das restrições do seu projeto?

Uma restrição é algo que limita a liberdade de ação de um gerente na condução de um projeto. Limitações normalmente não são coisas muito agradáveis e podem afetar o desempenho de uma iniciativa. Seria interessante, portanto, que sempre conhecêssemos a fundo as restrições que nos são impostas, certo?

Imagine por exemplo o projeto que tem como entrega a realização da cerimônia de abertura dos Jogos Olímpicos. Será que alguém cogitaria a possibilidade da ocorrência de um atraso neste caso? Certamente não. Isto significa que há para este projeto uma restrição de tempo fortíssima.

Agora pense na seguinte situação: uma empresa do setor automobilístico contrata uma empresa de tecnologia para desenvolver um software para controle de alguma operação industrial. Além de esperar um software que atenda às suas necessidades, a contratante exige que a contratada siga um processo de desenvolvimento de software específico definido por ela. Em princípio esta é uma restrição do projeto. Mas seria esta uma restrição forte? Tudo depende do contexto e do motivo pelo qual ela foi imposta. Pode ser que a contratante tenha tido boas experiências com esse processo proposto e queira por algum motivo padronizar a forma como seus fornecedores produzem seus softwares. Mas pode ser também que alguém na empresa automobilística tenha ouvido falar que tal processo é bom e sem nenhum conhecimento de causa tenha estabelecido a restrição. Pra piorar, vamos assumir que a contratada dispõe de um processo de desenvolvimento muito melhor do que o imposto pela restrição. Será que é certo simplesmente aceitar a situação? Ou seria melhor tentar mostrar ao cliente que o caminho a priori escolhido por ele não é o melhor. Na segunda possíbilidade, (situação em que a escolha pelo processo imposto foi baseada em opiniões vagas) a restrição não tem bases “fortes” e poderia com um pouco de empenho ser eliminada para o bem do projeto.

Já vi também algumas restrições de tempo criadas de forma equivocada. Em um determinado projeto o sponsor, que era um cliente externo à organização, havia definido que o projeto deveria ser finalizado em 4 meses. A equipe fez o planejamento e chegou à conclusão de que o tempo mais adequado para o atendimento de todas as necessidades seria em torno de 6 meses. O sponsor não aceitou e o cronograma foi comprimido para se adequar à restrição de 4 meses. O problema é que a compressão pode gerar riscos para o projeto, que se materializados podem ter o efeito inverso: uma data fim ainda mais distante que a original. E foi o que acabou ocorrendo neste caso específico. Tempo final de execução: 9 meses. Mais tarde descobriu-se que a finalização do projeto em 4 meses não era uma restrição de fato. O sponsor queria apenas dar uma pressionada no fornecedor, porque achava que de outra forma o produto esperado demoraria demais para ser finalizado.

O grande problema é que normalmente informações sobre a verdadeira força das restrições não estão disponíveis facilmente. Não caem em nosso colo de graça. Para conseguí-las, é preciso que o gerente de projetos se dedique a entender a fundo o contexto que cerca o projeto. E que seja corajoso o suficiente para questionar e negociar aquilo que parece não fazer muito sentido, independentemente de quem tenha imposto.

Conhecer a força das restrições é bastante útil também para que decisões importantes possam ser tomadas no decorrer do projeto. Em uma situação extrema, em que custo, qualidade ou prazo terão que ser sacrificados, qual deles escolher? O ideal seria nenhum, mas em alguns casos sabemos que as coisas não são tão perfeitas assim.

Portanto, ao assumir um projeto, antes de aceitar tudo aquilo que lhe é imposto, analise, questione, argumente. Pode estar aí a diferença entre seu sucesso ou fracasso.

Planejamento na medida certa, na hora certa

Planejamento é bom, todos nós sabemos. Mas a forma de planejar um projeto pode variar muito, de acordo com suas características. Sponsors mais conservadores sempre desejam um plano extremamente detalhado, com a especificação precisa de tudo que será feito, ainda antes do início da execução do projeto. O problema é que em muitas circunstâncias as informações disponíveis neste momento são insuficientes para um detalhamento desta natureza.

Há projetos em que se sabe perfeitamente o que se quer e o que tem que ser feito para a obtenção dos resultados desejados. Um bom exemplo deste caso é a construção de um prédio de apartamentos voltado para um público de renda mais baixa. As construções costumam ser extremamente padronizadas, com requisitos e processos produtivos bem conhecidos. Nesse caso creio ser possível a existência de um plano de projeto detalhado antes do início da execução. Ele poderá sofre mudanças e refinamentos, mas de modo geral se manterá relativamente estável.

Agora imagine um projeto que tenha como resultado permitir que um varejista passe a executar suas vendas também pela Internet. O número de possíveis caminhos a serem tomados no projeto de montagem de uma operação deste tipo é muito grande. E para cada conjunto de possibilidades, o trabalho a ser executado, o custo e o tempo de execução podem variar bastante. Para ilustrar vejamos algumas possibilidades de variação:

Em relação à parte de tecnologia a empresa poderia:

- Optar por criar uma estrutura própria de hardware e software para hospedar sua loja virtual
- Construir um software próprio e rodá-lo em um datacenter terceirizado
- Utilizar uma loja virtual já montada, com toda a infra-estrutura já pronta

Em relação às entregas para os clientes ela poderia:

- Utilizar os Correios
- Utilizar grande empresas de entrega, tais como DHL, Fedex, etc
- Utilizar pequenas empresas locais de entrega
- Utilizar um mix destas diversas opções

Em relação à estruturação de centros de distribuição (CDs):

- Poderia haver um único CD a partir do qual as entregas para todos os estados do Brasil ocorreria
- Poderia-se optar por CDs descentralizados em cada um dos estados da federação

Como já foi possível perceber existem muitas possibilidades. Claro que a documentação de algumas premissas poderia melhorar um pouco a situação, tornando o cenário mais definido. O problema é que as análises a serem feitas para que cada uma das decisões sejam tomadas não raro são complexas e podem ser melhor gerenciadas se fizerem parte do ciclo de vida do próprio projeto. Nesse caso não tem jeito: devemos recorrer ao velho e bom planejamento em ondas sucessivas. Na minha opinião um dos mais importantes conceitos a serem conhecidos e utilizados na prática pelos gerentes de projeto. Mas que no dia a dia costuma ser desconsiderado, mesmo quando sua utilização é a única opção viável para o sucesso.

Para quem não conhece o conceito, segue sua definição, presente no PMBOK:

Planejamento em ondas sucessivas / Rolling Wave Planning [Técnica]. Uma forma de planejamento de elaboração progressiva em que o trabalho que será realizado a curto prazo é planejado em detalhes em um nível baixo da estrutura analítica do projeto, enquanto o trabalho distante no futuro é planejado em um nível relativamente alto da estrutura analítica do projeto. Porém, o planejamento detalhado do trabalho a ser realizado dentro de mais um ou dois períodos no futuro próximo é feito conforme o trabalho está sendo terminado durante o período atual.

Traduzindo de forma bem pragmática, significa planejar o que se conhece de forma detalhada e o que não se conhece de forma mais superificial. Como à medida em que o projeto avança o conhecimento a seu respeito aumenta, significa também que o planejamento deve ser refinado várias vezes ao longo do projeto.

Assim, se você trabalha com projetos em que há muitas indefinições em relação ao que se quer ou em relação a como atingir os objetivos (grande maioria), não se orgulhe de, ainda antes de a execução começar, apresentar um plano super-detalhado mesmo para as últimas fases do projeto. Se este for o desejo do seu chefe, você o agradará num primeiro momento, mas certamente terá problemas em um futuro bem próximo. Quer apostar?