PMBOK: Ferramentas e Técnicas - Compressão do Cronograma do Projeto


Após a elaboração do primeiro cronograma do projeto podemos chegar à conclusão que o tempo necessário para a conclusão é impraticável porque:

  • Não cumpre com os requisitos do cliente;
  • Não respeita os compromissos contratuais;
  • Não permite disponibilizar o produto ou serviço no momento exigido pelo mercado (Time-to-market);
  • Não permite receber o bónus ou a compensação definida no contrato;
  • Não está de acordo com as datas em que necessitamos de libertar os recursos do projeto (Por exemplo, quando estes são necessários para outro projeto).

Face a uma situação destas existem vários mecanismos e técnicas que podemos usar para acelerar o cronograma do projeto, e conseguir que o mesmo termine na data desejada. No entanto, temos de ter presente que, qualquer que seja o mecanismo ou técnica usada, isso terá quase sempre como consequência um aumento do custo do projeto.
 
Se o primeiro cronograma estiver corretamente desenhado ele será o cronograma ótimo em termos de custo e alocação de recursos. Qualquer técnica de compressão do tempo conduzirá a um sub-ótimo em que o tempo necessário para executar o projeto diminui mas o custo aumento, assim como, qualquer técnica para reduzir o custo do projeto tenderá a conduzir-nos para um sub-ótimo em que o custo diminui mas a duração aumenta[1].

Quando isso acontece o segredo está em encontrar qual a duração ótima do projeto, sendo que a duração ótima é aquela que maximiza a redução do calendário minimizando o aumento de custos inerente.

As técnicas disponíveis para acelerar o cronograma do projeto, são as seguintes:

  • Adicionar recursos às atividades (Compressão ou crashing);
  • Contratação de Terceiros (Outsourcing);
  • Aumentar as horas de trabalho (Horas extra);
  • Executar atividades em paralelo (Paralelismo ou Fast Tracking);
  • Reduzir o âmbito / escopo do Projeto;
  • Reduzir a qualidade.

Vejamos com um pouco mais de detalhe cada uma destas técnicas.

Adicionar Recursos às Atividades (Compressão ou Crashing) – Compressão, ou na terminologia inglesa do PMBOK v4, Crashing, é uma técnica de compressão do cronograma do projeto, que é executada com o objetivo de diminuir a duração total do projeto.

Tipicamente, a diminuição da duração do projeto, realiza-se após a análise cuidadosa ao conjunto de alternativas de forma a selecionar a que permite maximizar a redução na duração com o menor custo adicional. Para reduzir a duração do projeto existe um conjunto relativamente reduzido de alternativas. Uma das opções mais comummente usada consiste no aumento dos recursos que estão afetos às atividades.

No entanto esse adicional de recursos deve ser encarado na perspetiva do aumento da produtividade, e não no mero aumento da quantidade, dado que esta ultima perspetiva é pouco eficiente, conduzindo habitualmente a aumentos de custo que não compensam as reduções de calendário.

Encarar a compressão numa vertente do aumento da produtividade, em que o objetivo final de redução do calendário, é obtido através do aumento da produtividade dos recursos afetos a determinadas atividades, permite extrair o máximo de valor dos recursos afetos às diversas atividades e, nesta medida, possibilita que a redução do calendário seja feita com o mínimo de custos.

Os recursos adicionados às atividades selecionadas podem vir de fora do projeto, ou ser retirados de outras atividades do projeto. Esta última opção é frequentemente usada para corrigir desvios de atividades que estão a decorrer com atraso.

A compressão deve iniciar-se pelas atividades que se situam no início do projeto. Desta forma controla-se o risco inerente à própria atividade de compressão e ganha-se espaço para eventuais dificuldades que surjam mais no final da execução.

A compressão deve incidir unicamente sobre as atividades do caminho crítico. Realocar recursos do projeto passa por avaliar as atividades que não pertencem ao caminho crítico, retirar-lhes recursos deixando que elas ocupem parte da folga que dispõem, e alocar esses recursos a atividades no caminho crítico, de forma a reduzir a sua duração e, consequentemente, a duração do projeto. No entanto este tipo de atuação deve ser efetuado com o cuidado necessário para que não se aumente de forma inaceitável o risco do projeto.

O que acima foi dito aplica-se, quando a técnica de compressão é usada durante o planeamento do projeto, ou para resolver problemas esporádicos no decurso da execução. No entanto, esta técnica é muitas vezes usada em “desespero de causa”, quando as atividades do caminho crítico derrapam, e a data de fim do projeto é mandatória, e não pode ser alterada. Neste caso, as questões com a eficiência são irrelevantes, e o que queremos é mesmo acelerar o projeto, mas devemos ter presente que, geralmente, o aumento de recursos não é proporcional à redução do tempo (Isto é, duplicar os recursos num projeto nunca reduz em metade a duração).

Contratação de Terceiros (Outsourcing) – Outsourcing é entregar a terceiros determinadas partes de execução do nosso projeto. Existem diversos tipos de outsourcing que estão relacionados com as condições de mercado, e com a maturidade da relação que estabelece, entre a empresa contratante e a organização contratada.

No entanto, e ao contrário do que é frequentemente referido, é preciso ter em conta que o outsourcing raramente representa uma redução do risco para a empresa cliente (Por exemplo, quando uma empresa faz outsourcing do seu centro de atendimento para reclamações de clientes, e se a prestação desse serviço for efetuada de forma deficiente, é o nome do cliente, e não o do prestador de serviço de outsourcing, que é colocado em causa. Sobre este assunto veja os 2 artigos publicados neste blog: O que é outsourcing? e Riscos do Outsourcing de SI/TI).

Aumentar as Horas de Trabalho – É uma forma simples de reduzir a duração do projeto, ou de recuperar de atrasos. Isto caso os colaboradores aceitem, trabalhar mais horas ou fazer horas extra, e não existam impedimentos legais que inviabilizem esta opção (Muitas vezes as organizações têm limitações contratuais que limitam muito o recurso a esta opção).

No entanto, esta opção nem sempre é eficaz, porque nem sempre o aumento de horas de trabalho tem, na prática, reflexo na quantidade do trabalho executado, até porque a produtividade tende a decrescer com o aumento do número de horas de trabalho.

Executar Atividades em Paralelo (Fast-Tracking) – Executar Atividades em Paralelo, significa realizar em simultâneo, atividades que, normalmente, seriam realizadas em sequência. Por exemplo, normalmente não devemos iniciar o desenvolvimento de um sistema, sem ter completado a fase de desenho da solução. Contudo, se necessitarmos de acelerar a execução do projeto podemos iniciar a construção do sistema, começando por aquelas áreas em que achamos que o desenho do sistema está mais adiantado, sem esperar pela conclusão da fase de desenho.

Executar atividades em paralelo implica uma determinada dose de risco e pode resultar na necessidade de repetir trabalho. Por exemplo, no exemplo anterior, se o desenho mudar em áreas que já começaram a ser construídas, isso pode obrigar a refazer algum trabalho. Uma boa regra é que 1/3 das atividades sequenciais podem ser realizadas em paralelo.

A grande vantagem da realização de atividades em paralelo, é que é uma técnica que permite comprimir a duração do projeto que, a maioria das vezes, não implica um aumento dos custos do projeto.

Para além do risco, a técnica tem ainda a desvantagem de ser bastante limitada por considerações de segurança e de qualidade.

Reduzir Âmbito / Escopo – Caso o cliente concorde, esta é sempre uma opção disponível. O difícil é obter o acordo do cliente.

Quando a necessidade de comprimir o calendário, decorre de atrasos na execução, é problemático explicar ao cliente que, no prazo de tempo previamente contratado, e pelo mesmo custo, lhe daremos menos funcionalidades.

A segunda dificuldade está em prioritizar as funcionalidades para decidir quais as que serão preteridas. Como é que fazemos? Deixamos para depois as funcionalidades que temos mais dificuldade em implementar? Ou aquelas que são menos importantes para o cliente? E, o cliente consegue prioritizar as suas necessidades?

A essas questões importa juntar que convêm saber claramente se o cliente prescinde definitivamente de algumas necessidades ou se as vai querer ver implementadas numa fase posterior.

Reduzir a Qualidade – Esta é, na nossa opinião, a técnica menos adequada para se obter uma redução do cronograma do projeto. Em primeiro lugar porque, geralmente, é adotada sem o acordo, ou o conhecimento prévio, do cliente; Depois porque, em alguns projetos, e em determinadas atividades, a redução da qualidade só é visível bastante tempo depois de o produto ou serviço entrar em funcionamento, o que coloca bastantes problemas e causa grande insatisfação nos utilizadores / clientes.

Costumamos dizer que, usar sistematicamente a qualidade para conseguir a redução da duração do projeto, é como ir caminhando e deixando bombas pelo caminho. Não podemos voltar para trás (isto é, dificilmente teremos mais projetos naquele cliente) e quando menos esperamos ou desejarmos, elas resolverão a rebentar (Lei de Murphi).




[1] Isto é verdade se partirmos do pressuposto que a qualidade e o número de requisitos se mantêm constante.  

Postagens mais visitadas deste blog

PMBOK v6: 7.4 Controlar os Custos do Projeto

PMBOK: Ferramentas e Técnicas – Método da Corrente Crítica (Parte 1)