Porque os Projetos atrasam e o que fazer sobre isso.
Como é possível completar mais projetos, mais rápido, sem sacrificar a qualidade ou o escopo, quando seus recursos já estão mais do que sobrecarregados?
Seus projetos sofrem de alguns desses efeitos indesejáveis?
- Atrasados;
- Recursos sobrecarregados;
- Mudanças em excesso (devido aos longos prazos do projeto);
- Recursos não disponíveis quando necessários (mesmo quando prometidos);
- Prioridades mutáveis e retrabalho.
Este artigo define as cinco razões relacionadas ao comportamento humano, responsáveis por seus projetos estarem atrasados e que, se você não abordá-las, continuarão a atrasá-los.
Nós descobrimos, através de anos de prática e pesquisa, que projetos sofrem de destinos similares. Examinando nossa biblioteca de mais de cem livros sobre gerenciamento de projetos e liderança descobrimos que o livro mais antigo e o mais novo, sobre gerenciamento de projetos, identificam as mesmas reclamações. Por mais de 50 anos os projetos têm sofrido dos mesmos efeitos. Por quê? O que poderia estar causando tal fracasso, universalmente, por tanto tempo? Caso você acredite que seu trabalho é diferente, também descobrimos que não importa qual tipo de projetos você gerencia. Projetos de energia, militares, tecnologia da informação, construção e dúzias de outros campos sofrem de destino idêntico.
Cinco razões, contra as quais seus projetos lutam, foram identificadas:
- Multi-tarefa nociva;
- Síndrome do Estudante;
- Lei de Parkinson;
- Dependência entre tarefas;
- Matemática do gerenciamento de projetos, onde 2+2=5.
Você deve se preocupar com essas cinco causas porque elas atrasam os benefícios e resultados do projeto para sua empresa e seus clientes. Essas causas também atrasam o fluxo de caixa de um projeto finalizado e permitem que sua equipe e seu cliente encontrem uma janela de oportunidade maior para fazer mudanças que ameacem o próprio projeto. Imagine a redução de pedidos de alteração se seu projeto fosse completado duas vezes mais rápido. Lembre-se, se você continuar fazendo o que sempre fez, continuará obtendo o que sempre obteve, projetos atrasados.
Causa Nº 1: Multitarefa Nociva
Você ou sua equipe enfrentam constantemente prioridades que mudam, fazendo com que interrompa uma tarefa e trabalhe em outra? Tem alguém esperando pela saída de sua tarefa para que possa fazer o trabalho dele/dela? Esta é a definição de multitarefa nociva. Dito isto, nem toda multitarefa é nociva. Quando ninguém está esperando pela sua saída não há nada de errado em comutar entre várias tarefas.
Por que fazemos multitarefas? Para alguns de nós é por causa do tédio de trabalhar em uma coisa por vez. Nossa mente exige estimulação mais alta e, portanto, continuamente mudamos de assunto. Freqüentemente a culpada é a má priorização. Nos pedem para iniciar várias tarefas simultaneamente e cada uma delas possui um “cliente” esperando por sua saída. Cada cliente quer que a tarefa dele progrida e constantemente pergunta “já terminou?”, forçando-nos a comutar repetidamente para a tarefa dele para que algo seja feito e reportar o progresso. Enquanto estamos trabalhando nesta tarefa, outros clientes pedem o status de suas respectivas tarefas. Este ciclo nos força a comutar tarefas repetidamente. Naturalmente, ao trabalhar numa tarefa você não está fazendo progresso em nenhuma outra. Se seus clientes contam com uma entrega rápida, eles levarão seus negócios para outro lugar. Para alguns clientes só o progresso já é suficiente. Não é necessário que seja rápido, desde que esteja sendo feito. Porém, mesmo se você tiver sorte o bastante para ter tais clientes, qual é o impacto em você e no seu negócio?
Qualquer quantidade de tempo não trabalhado numa tarefa significa que a tarefa está sendo atrasada mais do que seria se você se dedicasse ao seu término. Assim, a multitarefa sempre faz com que uma tarefa demore mais do que deveria. Entre outros fatores que se somam está o tempo de raciocínio que leva para “entrar no trilho” para tornar-se criativo. Para tarefas como engenharia, programação e redação esse tempo pode ser uma parte significativa do tempo total da tarefa quando se faz multitarefa. Para o trabalho manual isto pode incluir o tempo de ajuste da máquina, preparação das ferramentas e equipamentos apropriados e colocá-los de volta em seus lugares. Existem algumas tarefas onde o tempo de ajuste é desprezível e não é um fator, mas essas são poucas no mundo do trabalho intelectual. Estimativas indicam que o ajuste, ou tempo de raciocínio, pode igualar ou mesmo exceder o tempo real da tarefa, para tarefas altamente cognitivas. Um exemplo inclui escrever este artigo. Quando eu me distancio dele para fazer outra coisa qualquer e depois volto, preciso ler o segmento inteiro de novo para descobrir onde eu estava e o que estava pensando quando parei. Isto toma um tempo extra, que poderia ser devotado a mais escrita.
Pense como a multitarefa afetaria você numa fila de caixas da mercearia. Imagine que, em vez de atender uma pessoa por vez, o processo de pagamento no caixa incluísse a varredura de um produto de cada pessoa na fila, e então fosse repetido. Se há apenas uma pessoa na fila, o tempo necessário para o pagamento seria apenas o tempo necessário para varrer seus produtos, pegar seu dinheiro e empacotar suas mercadorias. Entretanto, se após você chegar na fila e um ou mais de seus itens tivessem sido registrados, outra pessoa entra na fila e, em vez de completar seu pedido, o caixa pegar um item desta outra pessoa, registrá-lo, e depois pegar um de seus itens, registrá-lo, e repetir. Agora demorará duas vezes mais para você completar sua compra. Enquanto o caixa está registrando seus itens e, simultaneamente, o da pessoa atrás de você, outra pessoa entra na fila. Agora o caixa pega um item seu, depois um da próxima pessoa, e depois um da nova pessoa, e repete. O que acontece quando outra pessoa entra na fila? Como você pode ver, quanto mais pessoas entrarem na fila, mais demorará para você completar sua transação. Você compraria nesta loja mais de uma vez? Não. Então, por que você faz isso com sua equipe e com seus clientes? A forma mais rápida de completar uma transação é começá-la e fazê-la até terminá-la. Você pode, então, concentrar-se na tarefa e no cliente. É mais rápido e fornece o melhor serviço ao cliente. Ninguém reclama, a menos que a fila fique muito grande. Quando comutamos de tarefas, o risco de problemas com a qualidade também aumenta. Nos esquecemos do que foi feito e do que não foi feito. Nós corremos para retornar à outra tarefa. Passamos por cima de pequenos detalhes em nosso ajuste. A pressão de clientes irados adicionam estresse ao trabalho, nos tornando menos satisfeitos e sujeitos a negligenciar um bom serviço. O envolvimento da gerência aumenta, para lidar com clientes “importantes” ou altamente impacientes, e a aceleração (despacho) começa a tornar-se uma forma de lidar com eles. Quanto mais e mais clientes começam a exigir um serviço mais rápido, a gerência começa a focar em métodos complicados de priorização para satisfazer a todos e manter os empregados focados em “fazer a coisa certa”.
A multitarefa nociva força as pessoas a dar estimativas maiores do que o necessário para as tarefas. Se você sabe que não lhe será permitido iniciar uma tarefa, trabalhar nela até terminar e depois prosseguir para a próxima tarefa, você será forçado a dar uma estimativa muito maior sobre quanto tempo levará para completar a tarefa. Se você sabe que levará dois dias para completar uma tarefa, mas também sabe que será interrompido, incluirá o tempo de interrupção na estimativa. Agora, uma tarefa de dois dias é estimada em 10 dias. Seu cliente esperará dez dias? Você decide. Seu cliente ficaria mais motivado a fazer negócio com você se você prometesse dois dias em vez de dez? Imagine a vantagem competitiva da promessa de menor duração. Imagine o melhor ambiente de trabalho criado para os membros da sua equipe quando você elimina os métodos complicados de priorização, a constante aceleração (despacho), os clientes zangados e a constante vigilância da gerência.
Nem toda multitarefa é nociva. Como saber a diferença? Lembre-se, multitarefa nociva é quando uma tarefa está sendo atrasada e a pessoa a quem você deve o resultado está esperando você terminar. Na verdade, a multitarefa nociva pode atrasar o término de todo o projeto. Porém, se ninguém estiver esperando pelo resultado então não é multitarefa nociva. Pode não ser eficiente, mas pode não significar muito. Por exemplo, lhe pedem para encher 100 envelopes e colocá-los no correio para amanhã. Já que o correio passa apenas uma vez ao dia e já é muito tarde para colocá-los hoje, não importa se você dobrar todos os papéis primeiro e depois envelopá-los (multitarefa), ou dobrar um papel e envelopá-lo e depois prosseguir para o próximo (sem multitarefa). Entretanto, se o carteiro estiver chegando a qualquer minuto e você tem um item crítico para enviar, seria insensato fazer multitarefa simplesmente para ser eficiente. Nesse caso a tarefa requer dobrar, envelopar, selar e enviar o lote, sem interrupção.
Algumas funções são guiadas por multitarefa. Nem toda função deveria eliminar a multitarefa. Por exemplo, uma secretária, um chefe de cozinha e muitas outras funções exigem a movimentação de muitas partes. Isto é multitarefa nociva? Não necessariamente. Devido à natureza muito curta da tarefa, e de tempos de espera embutidos na própria tarefa, o atraso é usualmente tolerável. Você pode precisar responder várias chamadas telefônicas e colocar pessoas na espera. Este atraso não é geralmente um problema até que se torne excessivo. Eventualmente o cliente determina um limite na quantidade de tempo que você pode permitir nos atrasos por multitarefa, antes que ele desligue e faça negócio em outro lugar. Todos nós gostaríamos que nossas chamadas fossem respondidas imediatamente, nosso problema fosse abordado sem ficar esperando, e então concluiríamos nossa chamada. Porém, devido à curta duração da transação, nós estamos dispostos a aceitar uma certa quantidade de demora.
A simulação de tarefas demonstra os efeitos da multitarefa nociva. Em simulações de projetos reais (usando a simulação com três projetos, de Tony Rizzo) realizadas em meus seminários, os estudantes realizam três projetos com multitarefa. Os efeitos criados durante este exercício são caos, confusão, montes de ordens e muitas atividades adicionais de “gerenciamento”. É bastante estressante. Quando eles terminam eu os desafio a fazer duas vezes mais projetos, seis no total, em menos tempo do que os três originais. Eles nunca acreditam que isto é possível. Eles também não querem enfrentar mais esse tanto de estresse. Entretanto, uma vez que removemos a multitarefa nociva, eles sempre fazem duas vezes mais projetos em menos tempo e sem o caos, sem gritaria, e muito menos estresse. A única diferença entre os dois eventos é a multitarefa nociva. Quando sua equipe está fazendo multitarefa isso exige uma sobrecarga considerável de gerenciamento. Alguém precisa manter o registro do que está sendo trabalhado, o status, o tempo previsto de término, e atualizar o cliente repetidamente. Cada pedaço dessa sobrecarga pode ser eliminada. Se sua experiência é parecida com isso, você tem muito a ganhar removendo esse obstáculo. Se você deseja conseguir fazer duas vezes mais, no mesmo período de tempo, e reduzindo o estresse, pare com a multitarefa. A figura abaixo fornece um exemplo gráfico dos resultados da multitarefa versus a não multitarefa.
Na Figura 1, note o término antecipado devido à remoção do tempo de ajuste (raciocínio). Também note o prazo de entrega de cada tarefa. Mesmo se os dois cenários demorarem a mesma quantidade de tempo total (zero tempo de ajuste/raciocínio), a vantagem de não fazer multitarefa é significativa. Se alguém estiver esperando pelos resultados da Tarefa-A antes que possa realizar sua tarefa, é fácil ver que sem a multitarefa a próxima tarefa pode começar consideravelmente mais cedo. E mais ainda, note que quando se faz multitarefa as três tarefas são completadas em rápida sucessão. Se os resultados de todas as três tarefas forem para o mesmo recurso, o destinatário agora herdou a carga da multitarefa. Isto cria uma pilha de trabalho completado que se move correnteza abaixo, assim como um excesso de trabalho em andamento. E tem mais, pode-se ter perdido tempo enquanto o próximo recurso esteve esperando pela saída. Ele pode ter ficado “ocupado” com trabalho, para ter certeza de que não seria pego sem ter o que fazer (e arriscar ser demitido). O tempo gasto nessa “ocupação com trabalho” não avançou o projeto e pode até mesmo ter contribuído para atrasá-lo.
Geralmente me perguntam sobre o “tempo morto” durante as tarefas. “Supõe-se que eu fique sentado, fazendo nada, quando eu chegar num ponto de uma tarefa onde eu estiver esperando por outros?” Não. Lembre-se, é apenas multitarefa nociva se alguém está esperando pelos seus resultados. Isto é, alguém está esperando pela sua saída para realizar o trabalho dele/dela. Por exemplo, se você está cozinhando e coloca o assado no forno, você está esperando o forno completar a tarefa dele. Você está livre para se mover para outra tarefa enquanto espera. Entretanto, esteja pronto para continuar imediatamente a tarefa anterior quando o forno tiver acabado, caso contrário, você queimará o assado.
Causa Nº 2: Lei de Parkinson
A multitarefa nociva faz os membros da equipe embutirem maior segurança nas estimativas de tarefas. Vamos examinar mais detalhadamente o tópico da estimação das tarefas e avaliar a validade e o prejuízo causado ao inflacionar a quantidade de segurança nas estimativas de duração. Quando atribui-se uma tarefa para uma pessoa, a primeira pergunta é: “Quanto tempo você vai demorar?” Você concorda que as pessoas têm uma tendência a incluir “proteção” na estimativa da duração, para acomodar fatores externos como “Murphy” e multitarefa? Pense numa tarefa recente que você estimou. Que nível de certeza você ofereceu? Foi 100%? Provavelmente não, pois algo poderia acontecer e impedir você até de completar a tarefa, tal como uma morte e, portanto, 100% de certeza não é alcançável. Que tal 50%? Mesmo neste nível de certeza você estaria atrasado em 5 de cada 10 vezes. Talvez sua oferta tenha sido próxima a 90%. Isto significa que 9 em cada 10 vezes você está no prazo. Isto parece razoável? Que nível de certeza você exige de sua equipe? Você exige que suas estimativas sejam precisas toda vez? Ou você está bem com atrasos em 5 de cada 10 vezes? A maioria dos gerentes quer que as pessoas forneçam estimativas “precisas”, o que não faz sentido porque uma estimativa, por definição, é apenas uma aproximação.
Intelectualmente nós entendemos que estimativas não são exatas. Mesmo assim, nós as exigimos. Por quê? Há uma crença subjacente de que se podemos determinar precisamente o tempo para cada tarefa, e nos assegurarmos que cada tarefa seja terminada “no prazo”, então o projeto terminará no prazo. Porém, nós também sabemos que o objetivo não é terminar cada tarefa no prazo, mas completar o projeto no prazo. A realidade do trabalho do projeto é que a incerteza existe e, portanto, o tempo das tarefas não pode ser determinado, apenas estimado. O resultado da exigência de estimativas precisas é que as estimativas de duração são convertidas em compromissos. Assim, para fornecer uma estimativa realista devemos levar em conta todas as coisas que podem impactar na duração da tarefa, embutindo segurança.
Quando uma “pequena” segurança é adicionada às estimativas elas não são consideradas como irrazoáveis porque, mentalmente, nós adicionamos a segurança considerando uma distribuição normal do tempo. Numa distribuição normal, 50% do tempo está de um lado da média e 50% do tempo está do outro lado da média. Assim, avançar de 50% de probabilidade para 80% não parece ser significativo (veja a Figura 2).
Quando comparar os dois gráficos verá que a “pequena” segurança embutida é, na realidade, bastante grande. Quando maior a incerteza da tarefa, mais a cauda cresce. O resultado é uma tarefa com aproximadamente metade de sua duração estimada sendo segurança.
O único a adicionar segurança é o membro individual da equipe? Nunca. Posteriormente, o gerente toma as tarefas estimadas com segurança e adiciona a sua própria segurança. Em cada nível de gerência mais segurança é adicionada (ver Figura 4).
Essa segurança adicional desnecessariamente prolonga a data de término do projeto e, de fato, não protege contra a incerteza. Algumas vezes outra doença ocorre, isto é, todo mundo inflaciona suas estimativas porque sabem que o nível acima irá cortá-las. Já que o recurso não sabe o quanto será arbitrariamente cortado, ele “chuta” o quanto inflacionar a duração. Continuando, já que o próximo nível não tem idéia de quanta segurança foi adicionada, ele corta “chutando” o quanto de segurança ele acha que foi adicionada. O processo todo é ridículo.
Se há tanta segurança embutida em cada tarefa, por que as tarefas continuam a atrasar? Não deveriam elas terminar no prazo ou antes? Se você concorda que a segurança é embutida para levar em conta o desconhecido (Murphy), e que Murphy não ataca toda tarefa como previsto, então a maioria das tarefas não deveria terminar no prazo. Deveria terminar antes. Apenas uma tarefa ocasional, que teve tudo imaginado durante a estimação, e aí teve uma sorte muito pior, deveria atrasar. Se as tarefas não estão terminando antes na maior parte do tempo, então a segurança está sendo perdida. Mesmo uma tarefa que termina no prazo é inaceitável, pois aproximadamente metade do tempo estimado estava reservado para eventos que nunca ocorreram (Murphy).
O mais notável ainda é que as pessoas se esforçam para cumprir o pedido absurdo de fornecer estimativas precisas. Por quê? Você concordaria que a maioria das pessoas quer ser considerada confiável? Se é assim, isto significa que nós tentamos cumprir nossos compromissos, certo? E se isso é verdade, o resultado é que nós adicionamos segurança e lutamos para impedir que ela seja removida por outros. Se temos segurança extra embutida, que não foi necessária, então usamos esse tempo extra para fazer um trabalho melhor, em vez de reportar um término antecipado. Afinal, se exigimos 6 semanas e entregamos em 4 semanas, qual será a “recompensa” por entregar antes, na próxima vez que pedirmos 6 semanas para uma tarefa? Nossa segurança será cortada. Isto pode fazer com que falhemos em nosso compromisso, nos atrasando e nos tornando não confiáveis. Este fenômeno é tão predominante que possui seu próprio nome: Lei de Parkinson. Esta lei expressa que: “O trabalho se expande para preencher o tempo disponível.” Agora você deve concordar que as pessoas realmente adicionam segurança, mas ela não está sendo usada apropriadamente. Sua prova é que a maioria das tarefas não terminam antes, como seria esperado.
Causa Nº 3: Síndrome do Estudante
A Síndrome do Estudante também é conhecida como procrastinação. A grande diferença é a razão para adiar o trabalho. Procrastinar é ser preguiçoso ou irresponsável. A Síndrome do Estudante é um mecanismo de defesa natural. Significa adiar o trabalho até o último momento possível, não porque somos preguiçosos, pelo contrário, estamos trabalhando duro. Todos caímos presas da Síndrome do Estudante ocasionalmente. Ela ganhou esse nome pela forma como os estudantes lidam com o dever de casa. Imagine seu professor dizendo que você tem uma prova final em 19 semanas. Ele lhe dá todo o material, o livro, os objetivos que serão testados e a data. Quando você começa a estudar? Na véspera da prova. Por quê? Você tem tempo, é por isso. Outras tarefas pressionam mais e, portanto, você atrasa o início de uma tarefa até o último momento, para lhe dar tempo de completar outro trabalho, muito provavelmente também sendo feito no último momento.
Geralmente as pessoas dizem que não podem estimar com qualquer precisão o quanto uma tarefa irá durar. Eu discordo. A evidência para esta afirmação é que as pessoas realmente sabem o último minuto possível que elas têm para iniciar uma tarefa, ou arriscar atrasar. Quando foi a última vez que você adiou algo até o último minuto e foi capaz de escolher o último minuto real? Você trabalhou a noite toda para completar a tarefa e imprimiu o resultado exatamente antes da grande reunião. O papel ainda está morno na entrega, mas você conseguiu. Esse problema torna-se mais sério quando consideramos as implicação sobre a qualidade. Sim, você escolheu o último momento possível para completar uma tarefa, mas qual foi a conseqüência em potencial sobre a qualidade? Se algo desse errado não haveria tempo para consertar. Com qual freqüência você erra a escolha do último minuto em tarefas importantes? Eu sugiro que é raro. Eu sei disso por experiência própria. Portanto, podemos concluir que a maioria das pessoas realmente sabem o quanto uma tarefa irá levar (dada alguma probabilidade) quando elas podem se dedicar a ela. Se você quer estimativas mais precisas (mas nunca precisas), identifique a data de entrega e pergunte-se: “Se eu iniciar esta tarefa no último minuto, quando isso seria?” Agora você tem a estimativa da duração da tarefa.
A dificuldade da estimação das tarefas não é conhecer o quanto a tarefa durará, mas “chutar” quantos outros fatores devem ser considerados, já que sabemos que não nos será permitido trabalhar na tarefa sem interrupção. Se as pessoas ainda não estão certas sobre o quanto uma tarefa durará, provavelmente é porque não sabem quando elas conseguirão todas as entradas necessárias para realmente começar a tarefa, sem ter que parar e coletar mais informação. Isto não é um problema. Lembre aos recursos que estão fornecendo as estimativas que você só está interessado em quanto tempo levará para completar as tarefas sem interrupções, com todas as entradas necessárias disponíveis. Depois documente as entradas necessárias para assegurar que não lhes será pedido que iniciem uma tarefa sem que tais entradas estejam sob sua posse. Seu trabalho como gerente do projeto é garantir que eles tenham o que é necessário para realizarem o trabalho deles.
Enquanto você sobrecarregar as pessoas com tarefas e permitir que elas inflacionem os prazos para acomodar outras tarefas, você perpetuará a síndrome do estudante. Esse problema é ampliado pela multitarefa. Nós temos nossa equipe trabalhando em múltiplas tarefas com durações inflacionadas e esperamos que eles priorizem tais tarefas. Tarefas urgentes terão precedência sobre as tarefas importantes. Isto encoraja o embutimento de segurança nas tarefas, que fornece mais tempo do que o realmente necessário, então atrasamos o início das tarefas até que tenhamos absolutamente que começar, devido às demandas concorrentes. E o que acontece quando a tarefa realmente encontra um problema? Onde está a segurança? (Uma pergunta melhor seria: “Quando é a segurança?”) Está no passado. Não podemos usá-la mais (ver Figuras 5 e 6).
Algumas pessoas enfatizam que tudo isto não pode ser verdade. Na verdade, quando minha equipe me fornece uma estimativa eles quase sempre atingem essa estimativa. Isto pode ser verdade. Entretanto, é verdade porque é uma profecia auto-realizável. A tarefa torna-se vítima das questões mencionadas anteriormente, fazendo com que seja completada como previsto, porque as pessoas querem ser vistas como confiáveis. Como você pode ver, se a tarefa é iniciada imediatamente e não há problemas sérios, a segurança embutida é consumida pela Lei de Parkinson. Se nós não começarmos a tarefa imediatamente e ocorre um problema, a tarefa será atrasada. Se começarmos a tarefa atrasada (síndrome do estudante) e nada dá errado, nós completamos a tarefa “no prazo”. De um jeito ou de outro, a segurança foi gasta. Esse é um tempo que fez com que a duração do seu projeto seja estimada muito além do que era necessário. Isso também torna seu projeto menos competitivo.
Causa Nº 4: Dependência Entre Tarefas
Em projetos, todas as tarefas dependem de outras. Em seu livro "The Mythical Man Month" ("O Mito do Homem-Mês"), Fred Brooks respondeu à pergunta sobre como os projetos atrasam: "Um dia por vez". Você já notou que se a data final do seu projeto desliza, é quase impossível recuperá-la? Você também já notou o quão fácil é atrasar, mas o quanto é difícil adiantar? Se já, então você entende os problemas criados pela dependência entre tarefas.
Um efeito negativo causado pela dependência entre tarefas é explicado no seguinte exemplo. Você tem uma tarefa que foi estimada em 5 dias, incluindo a segurança, a inicia imediatamente e a completa "mais cedo". A pessoa que recebe sua saída está pronta para usá-la imediatamente? Geralmente não. Portanto, se você entregar os resultados em 3 dias, a próxima pessoa não vai tocá-los por 2 dias adicionais, porque ela não está agendada para começar a tarefa dela até aquele dia. Assim, a segurança embutida é perdida, mesmo com a tarefa sendo terminada antes. Para superar esse problema você precisa ter um sistema de projetos que garanta que todas as tarefas comecem, não quando elas estão agendadas para começar, mas quando as entradas necessárias estiverem disponíveis. Isso é especialmente vital com as tarefas no caminho crítico (ou na corrente crítica).
Outro efeito negativo causado pela dependência entre tarefas é bem conhecido na teoria da probabilidade, chamado de "probabilidade de eventos dependentes" (também conhecido por outros nomes). Essa teoria afirma que o tempo total requerido para eventos dependentes, em termos de probabilidade, é o produto da probabilidade de todos os eventos dependentes. Veja como isso impacta você (Figura 7).
Se você tem três tarefas que são dependentes uma da outra, e cada uma tem uma chance de 90% de ser terminada no prazo, qual é a probabilidade de todas as três serem completadas no prazo? Cerca de 73%! Devemos calcular a probabilidade de terminar a Tarefa-1 (90%) e depois calcular a probabilidade de terminar a Tarefa-2, dada sua dependência com a Tarefa-1 (90% x 90% = 81%). Como pode ver, a probabilidade de terminar a Tarefa-1 e a Tarefa-2 no prazo é de apenas 81%. Podemos então calcular a probabilidade de completar a Tarefa-3, dada sua dependência com a Tarefa-1 e a Tarefa-2 serem completadas no prazo (90% x 90% x 90% ? 73%). Com apenas três tarefas, cada uma com 90% de chance de terminar como prometido, há apenas uma chance de 73% de terminarmos, de fato, todas as três como prometido. Não precisamos de muitas tarefas para alcançar uma probabilidade zero de terminar o projeto no prazo.
Você pode estar pensando: "Eu não tenho esse problema, porque eu realizo as tarefas em paralelo, em vez de em série." Vamos examinar esta solução (Figura 8).
Se cada tarefa possui uma chance de 90% de ser feita como planejado, qual é a chance do projeto todo terminar no prazo? Sua primeira reação pode ser 90%. Porém, já que o término do projeto depende do término de todas as tarefas, devemos usar o produto de cada evento dependente para determinar o tempo provável de término. Neste caso, vamos multiplicar 90% de cada tarefa em paralelo, obtendo a mesma chance de 73% de término no prazo. Agora você pode ver porque tentar fazer com que cada tarefa termine no prazo não significa que o projeto terminará no prazo. Será exigido que toda tarefa dependente termine como planejado, para que o projeto termine no prazo. Esse efeito fez com que os gerentes de projetos concluíssem que a única forma de terminar um projeto no prazo é garantir que todas as tarefas, realmente, terminem no prazo. Tal solução exigiria que todas as tarefas sejam estimadas com 100% de precisão. Mesmo se isso fosse possível, faria com que os tempos das tarefas tivessem uma duração inimaginável.
Para entender melhor como os atrasos são passados adiante, mas os adiantamentos não, examine a Figura 9.
Este projeto foi planejado para durar 17 dias. O quanto adiantado ele poderia terminar se a primeira tarefa estivesse cinco dias adiantada? Os mesmos 17 dias. A razão é que nós somos dependentes do término de todas as cinco tarefas. Portanto, mesmo se uma tarefa estiver adiantada, o projeto não terminará adiantado em nada. E se as primeiras quatro tarefas terminassem 5 dias antes? A duração do projeto ainda seria de 17 dias. Agora pense na duração do projeto se apenas uma tarefa atrasar 5 dias. O projeto levaria 22 dias. Como podemos ver, adiantamentos não são passados adiante, atrasos sempre são.
Uma dependência adicional não discutida, e geralmente proibida na metodologia do caminho crítico, é a dependência de recursos. Na imagem seguinte (Figura 10),
temos um projeto que inclui dependências de tarefas e de recursos. Note que as tarefas A e D ambas requerem o uso do recurso "programador". Para completar as tarefas C e D temos que completar A e B. Para iniciar a tarefa D também precisamos completar a tarefa A, devido à dependência de recurso. Dado que cada tarefa possui uma probabilidade de terminar no prazo de 90%, qual é a probabilidade deste projeto terminar no prazo? Apenas 73%! Embora não haja uma seta ligando a tarefa A à tarefa D, a dependência permanece. Com essa dependência encontramos todos os problemas mencionados previamente. Entretanto, dependências de recursos não são calculadas em redes de projetos tradicionais.
Vamos examinar o ciclo vicioso de lógica que ocorre devido ao fato de fazer as estimativas se tornarem compromissos. Lembre-se que as pessoas querem ser vistas como confiáveis e, portanto, tentam completar as tarefas o mais próximo da data compromissada quanto possível. Isto impede que a proteção seja removida nas estimativas futuras e as ajuda a serem vistas como confiáveis.
Quando um projeto está atrasado, qual é a resposta típica? Conduza uma atividade de lições aprendidas e identifique as tarefas que atrasaram o projeto. Qual é o comportamento criado por essa descoberta? Da próxima vez que criarmos um plano de projeto, adicionaremos mais segurança e detalhes a esses tipos de tarefas. Porém, se adicionarmos mais segurança e não mudarmos como medimos as pessoas, para permitir que os términos antecipados e atrasados se compensem entre si, então o projeto não terminará "no prazo" da próxima vez. Igualmente, se nas tarefas culpadas por atrasar o projeto adicionarem mais segurança, esse projeto será planejado para durar ainda mais. Se os ganhos e os términos antecipados não se compensarem e o projeto ainda não terminar no prazo, nas lições aprendidas descobriremos quais tarefas atrasaram o projeto. Como você pode ver, isso torna-se um laço negativo. Estamos atrasados, culpamos tarefas, adicionamos mais segurança, ficamos atrasados de novo, culpamos tarefas, adicionamos segurança, e assim por diante. Eventualmente, seus clientes procurarão seu concorrente, porque seus projetos demoram demais. Seus clientes determinam o quanto você pode aumentar o cronograma por conta do gerenciamento deficiente.
Uma última questão relacionada com tarefas que se integram umas com as outras. Qualquer lugar em que há integração de tarefas há riscos adicionais. As coisas nem sempre se encaixam como esperamos. O que acontece quando tarefas que se integram têm problemas? O projeto é atrasado. Sim, você poderia colocar mais segurança nesses pontos, mas ela seria desperdiçada como já descrito. Esse problema pode ser superado apenas por um método de agendamento que considere a variação e a incerteza nas durações das tarefas. Ele não pode ser superado simplesmente declarando que as pessoas "devem" terminar no prazo. O método de agendamento que gerencia essas questões é chamado Corrente Crítica. Encorajo os leitores a lerem "Corrente Crítica", de Eliyahu Goldratt, para mais informação sobre o assunto.
Causa Nº 5: Matemática do Projeto 2+2 = 5
Em gerenciamento de projetos as coisas nem sempre são o que parecem. Esse efeito negativo é bastante simples, embora geralmente negligenciado. Se você tivesse um projeto com duas tarefas, cada uma com 2 dias de duração, quanto tempo ele levaria? Sem considerar as questões acima, a resposta acima seria 4 dias. Porém, você sabe que a probabilidade é muito menor do que você pensava. Eis o cenário: você está trabalhando na Tarefa-1 e sua saída vai para o recurso para realizar a Tarefa-2. Digamos que você é um santo e que começa sua tarefa no prazo, trabalhou nela até terminar, sem multitarefa, e completou-a no final do dia 2, como prometido. É normal completar seu trabalho, imediatamente levar seus resultados para a próxima pessoa (como se você realmente soubesse quem é) e entregá-los a ela para que comece? Não. Todavia, você conclui que terminou no prazo, então você relata o término para obter o crédito de ter terminado no prazo e dá o dia por encerrado. Na manhã seguinte você pega seu café, lê seu e-mail e faz qualquer outro trabalho pendente. Então você pega seus resultados de ontem e os entrega à próxima pessoa na fila. Agora perdemos metade de um dia.
Parte II do cenário: Será que a pessoa para quem você entregou os resultados irá parar imediatamente o que estiver fazendo, limpar a mesa e começar a trabalhar no próximo passo para esse entregável? Não. Ela vai lhe agradecer pela entrega, apreciar que você está geralmente no prazo e trocar fofocas com você. Ela reconhece que não há pressa para começar imediatamente, já que existe uma rede de segurança embutida nas estimativas de duração. Agora é a hora do almoço. Ela retorna ao escritório, realiza mais algum outro trabalho, e pensa em iniciar sua tarefa, mas, é o final do dia, e nada como um novo início amanhã. Ela vai prá casa. Agora, outro meio dia está perdido. Quando ela começa a tarefa na manhã seguinte, já está um dia atrasada, causando atraso para outros, e agora o projeto está atrasado. Assim é como uma tarefa de 2 dias mais uma de 2 dias resulta em 5 dias. Alguns argumentam que a segunda pessoa muito provavelmente irá acelerar e terminar em um dia, e o projeto não ficaria atrasado. Isto poderia acontecer. Provavelmente acontece freqüentemente. Mas isso admite que a tarefa não era mesmo uma de dois dias, mas uma tarefa de um dia com um dia de segurança, que foi perdida, atrasando o projeto. Isso pode facilmente ser superado garantindo que cada nome de tarefa inclua a transferência. Por exemplo, em vez de "Completar o relatório" como uma tarefa, poderia ser "Marketing obtém o relatório completadov. Agora a pessoa que realiza a tarefa não ganha crédito por completá-la até que esteja nas mãos do próximo recurso. Além disso, a pessoa que realiza a tarefa não pode marcar sua própria tarefa como terminada. Apenas o recurso que precisa de sua entrega pode validar que você “terminou”. Isto impede entregas atrasadas assim como fornece ao próximo recurso na fila a oportunidade de rejeitar resultados com má qualidade, que impactem seu trabalho. Este método foi chamado de efeito "papa-léguas" pelo Dr. Goldratt. O efeito é similar à corrida de revezamento, onde devemos ter certeza que a próxima pessoa na fila está sempre pronta para iniciar o trabalho numa tarefa do projeto quando entregue. Muitos gerentes de projetos vão tão longe quanto contatar o próximo recurso na fila e notificá-lo sobre quando sua tarefa predecessora terminará, para que tenha oportunidade de limpar sua mesa em preparação para o trabalho vindouro.
CONCLUSÃO
Agora você conhece as cinco principais doenças que fazem seus projetos atrasarem. Para remover esses obstáculos você precisará parar a multitarefa nociva, desenvolver um sistema que permita que as tarefas adiantadas e atrasadas se compensem entre si, que leve em conta a probabilidade dos eventos dependentes, que pare os efeitos da Lei de Parkinson, que garanta que, quando uma tarefa é completada, o resultado aparece quase instantaneamente para a próxima tarefa na fila, e que pare a prática de adicionar segurança a cada tarefa.
Sobre o Autor
Allan Elder é presidente da No Limits Leadership, Inc., uma empresa de consultoria dedicada a ajudar as organizações a entregar mais projetos, mais rápido, atráves da liderança eficaz. Allan trabalhou como diretor de GSI (Gerenciamento de Sistemas de Informação) para a segunda maior empresa de seguros corporativos e a maior empresa de segurança na Califórnia. Allan foi certificado como PMP, é um “Jonah” na Teoria das Restrições, possui bacharelado em Telecomunicações, mestrado em Gerenciamento de Projetos e Ph.D. em Organização e Gerenciamento. Além de seu trabalho em consultoria, Allan é o principal instrutor de gerenciamento de projetos para a Universidade da Califórnia, Irvine, prestou consultoria e lecionou para a UCI Graduate School of Business, e foi um Examinador Sênior para o California Award for Performance Excellence (CAPE) por três anos. Allan pode ser contatado em aelder@nolimitsleadership.com.
Sobre o Tradutor
Adail Muniz Retamal é diretor da Heptagon Tecnologia da Informação Ltda, empresa de consultoria e treinamento focada na aplicação da Teoria das Restrições em geral, e da Corrente Crítica em particular, à Engenharia de Software, metodologias ágeis de gerenciamento e desenvolvimento de software, atuando como catalisador da mudança organizacional, além de ajudar as organizações a construírem sua estratégia e tática para alinhar seus esforços com suas metas. Adail é Engenheiro Eletricista/Eletrônico, atuou como consultor, instrutor e arquiteto de soluções para a Borland Latin America por 4,5 anos. Lecionou em universidades públicas e privadas. É palestrante, articulista e está escrevendo um livro. Adail pode ser contatado em adail@heptagon.com.br.
Autor: Allan Elder, No Limits Leadership, Inc.
Versão traduzidaBrasileira: Adail Muniz Retamal, Heptagon TI Ltda
