As Cinco Doenças do Gerenciamento de Projetos - 5: Matemática do Projeto

Início   Anterior

Causa Nº 5: 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.


Início   Anterior