Hogar / CL / Quando Você Deve Matar um Projeto?

Quando Você Deve Matar um Projeto?

Os projetos tendem a se tornar os “queridinhos” de qualquer gerente de projeto. Eles esforçam-se para planejá-los corretamente, para escolher as pessoas certas para participar e configurar todas as resoluções necessárias relacionadas a incertezas para certificarem-se de que o projeto evolua adequadamente. No entanto, muitas vezes, nem o planejamento mais coerente salvará um projeto, e os gerentes devem decidir que é hora de acabar com o empenho. Resumidamente, a lista é como segue: • Não há retorno de investimento relacionado ao projeto • O projeto não é bom o bastante • Um projeto mais significante foi apresentado • O planejamento do negócio mudou • O benefício original do projeto não existe mais No entanto, determinar quando um projeto deve ser rescindido não é fácil, por isso a Rosanne Lim criou um documento de apoio das razões pelas quais um projeto deve ser “assassinado” . Ao fim da lista há um dos mais bem sucedidos medidores de validade de projetos: Os benefícios iniciais do projeto não são mais válidos: Pode haver uma diversidade de razões para isto ocorrer. No ambiente de TI, por exemplo, alguém pode ter tido a mesma ideia e já ter lançado o produto no mercado. O mesmo é fato em todas as indústrias. As mudanças no meio empresarial podem significar que não será mais rentável continuar o trabalho quando os benefícios já não são os mesmos. Enquanto pode parecer uma ideia ruim acabar com qualquer projeto uma vez que este já foi iniciado, a verdade é que qualquer projeto é tão bom quanto as razões por trás deste. A melhor maneira de saber quando rescindir um projeto é antes mesmo de tê-lo iniciado: com planejamento adequado, levantamento de requisitos e alinhamento de objetivos empresariais, é possível evitar muitos dos problemas mencionados neste artigo.

Sobre Matthew Kabik

Matthew Kabik is the former Editor of Computer Aid's Accelerating IT Success. He worked at Computer Aid, Inc. from 2008 to 2014 in the Harrisburg offices, where he was a copywriter, swordsman, social media consultant, and trainer before moving into editorial.

Compruebe también

PMI e ITIL: ¿Cómo diferenciarlos?

Con frecuencia en TI suponemos que todos sabemos lo que cada uno hace, pero Fahrudin Golos sí sabe que ese no siempre es el caso. En respuesta a un correo electrónico reciente donde un lector pidió aclaración sobre las diferencia

Leave a Reply

Your email address will not be published. Required fields are marked *