O rastreamento rápido e o crashing podem colocar seu projeto de volta no cronograma

Os gerentes de projeto devem avaliar seus cronogramas semanalmente para garantir que seu projeto permaneça no caminho certo. Se o projeto começar a andar à deriva, há uma série de técnicas que podem ser usadas para voltar ao cronograma. Mostof estas não são dramáticas.

Dicas na sua caixa de entrada

Procura de gerenciamento de projetos de TI especializado? Receba a ajuda que precisa na newsletter gratuita de Gestão de Projectos da TechRepublic, entregue todas as quartas-feiras.

Registe-se automaticamente hoje!

No entanto, vamos assumir que o seu projecto começa a deslizar dramaticamente. Pode não ser possível voltar ao normal através das técnicas típicas de gerenciamento de cronograma. Vamos ainda assumir que o prazo do projeto é fixo e não pode ser alterado. Neste caso você pode precisar empregar meios mais dramáticos. Duas técnicas a considerar são o rastreamento rápido e o crashing.

Rastreamento rápido

Rastreamento rápido significa que você olha para atividades que são feitas em sequência e as atribui parcialmente em paralelo. Forinstance, normalmente você não começaria a construir uma solução até que o designwasse fosse concluído. No entanto, se você fosse um rastreamento rápido, você começaria a construir a solução em áreas onde você sentiu que o projeto era bastante sólido sem esperar que todo o projeto estivesse concluído. O rastreamento rápido envolve sempre um risco que pode levar a um aumento do custo e algum retrabalho mais tarde. Por exemplo, no exemplo de desenhar e construir uma aplicação, é possível que o design seja alterado antes de ser finalizado, e essas alterações finais podem resultar na necessidade de refazer alguns dos trabalhos de construção já em andamento.

Uma boa regra geral é que atividades seqüenciais podem, às vezes, ser aceleradas em até 33%. Em outras palavras, se você refazer o rastreamento rápido, você pode iniciar a segunda de duas atividades seqüenciais quando a primeira atividade estiver 66% completa. Há um risco envolvido. No entanto, isto parece ser um nível de risco de rastreamento rápido que é normalmente aceitável.

Crashing

“Crashing” o cronograma significa lançar recursos adicionais para o caminho crítico sem necessariamente obter o mais alto nível de eficiência. Por exemplo, digamos que uma pessoa estava trabalhando em uma atividade de dez dias no caminho crítico. Se você estava realmente desesperado para encurtar esse prazo, você poderia adicionar um segundo recurso a essa atividade. Na verdade, o recurso pode não ter todas as habilidades certas e ele pode trabalhar cinco dias apenas torturou o tempo total em dois dias.

Na superfície, o tradeoff anterior pode não fazer sentido. Afinal, por que você teria uma pessoa trabalhando cinco dias apenas para reduzir a anactividade em dois dias? Não é eficiente. No entanto, consegue imaginar um projecto que fosse tão importante que estivesse disposto a fazer este tipo de troca? Pense nos projectos YR2K. Quando o final de 1999 estava rolando, as empresas estavam jogando recursos nos projetos; desesperadas para concluí-los a tempo. Eram rápidos.

Recursos adicionais podem vir de dentro da equipe do projeto, ou podem ser emprestados temporariamente de fora da equipe. Um dos objetivos de quebrar o cronograma é minimizar o custo incremental. No entanto, em troca de completar algum trabalho antes do cronograma, a quebra geralmente leva sempre a um custo incremental adicional para o projeto. Se você estiver disposto e for capaz de gastar mais para acelerar o cronograma, o acompanhamento rápido pode ser uma opção viável para você.

Deixe uma resposta

O seu endereço de email não será publicado.