Por que Projetos falham

Senhores, peço desculpas por não ter postado nada nesses dias, pois etou envolvido em uma série de projetos, e como todos que trabalham com isso tempo é uma coisa rara. Mas estou de volta, segue uma matéria ótima sobre o que não devemos fazer, além de observar, pois ai esta a mais pura verdade.

Saiu um artigo muito bom na ComputerWeekly, escrito por Tony Collins ,sobre o pesadelo dos gerentes de projeto: projetos que falham. Collins postulou 20 ‘dicas’ práticas, baseadas na observação do dia-a-dia. Além de engraçada, a lista é bastante educativa.

- Projetos com orçamentos e cronogramas realistas não são aprovados;

- Quanto mais desesperada é a situação, mais otimistas são os relatórios de progresso;

- Um usuário é alguém que rejeita o sistema porque é exatamente aquilo pelo que ele pediu;

- A diferença entre o sucesso e o fracasso de um projeto é uma boa compania de Relações Públicas;

- Nada é impossível para a pessoa que não tem de fazê-lo;

- Todo projeto falho e ultra-ambicioso tem por base uma série de pequenos projetos bem sucedidos tentando escapulir;

- Um ‘congelamento’ na mudança derrete sempre que pressão é aplicada;

- Você entendeu o que eu disse, não o que eu quais dizer;

- Se você não sabe para onde está indo, apenas fale sobre especificações técnicas;

- Se a princípio você não tiver sucesso, mude o nome do projeto;

- Todo mundo quer um gerente de projeto mais forte – até que eles consigam um;

- Somente idiotas confessam aquilo que sabem realmente (obrigado Presidente Nixon)

- O prior gerente de projetos é aquele que dorme a noite;

- Um projeto falido sempre tem benefícios listados no tempo futuro;

- Projetos não falham na conclusão, falham na concepção;

- Visões normalmente são curáveis;

- Projetos ultra-ambiciosos não podem falhar nunca se tiverem inicio, meio, e nenhum fim;

- No Governo, nunca punimos o erro, só sua divulgação;

- O caminho mais difícil é, a longo prazo, o mais fácil;

- Um realista é algouém que está, no momento presente, desapontado com o futuro;

Por hoje é só....


texto extraído de: papogp.com

10 dicas para definir o Escopo

Definir o Escopo do Projeto é uma etapa de vital importância. Se não for feita da forma correta, o projeto estará fadado ao fracasso, uma vez que é o escopo que determina o que irá (e não irá) ser feito/produzido/entregue ao termino do projeto. Um escopo mal-estruturado levará inevitavelmente a falhas de cronograma e de orçamento, uma vez que os problemas decorrentes da má especificação se farão presentes e a equipe terá que achar caminhos alternativos para a execução do projeto. Por fim, um escopo mal definido resulta em um cliente insatisfeito, uma vez que o mesmo pediu X e recebeu Z, levando a uma insatisfação do executivo, do time do projeto e do gerente. O efeito cascata disso pode ser terrível, como uma caça-às-bruxas para determinar de quem foi a culpa, quando na verdade a culpa foi do escopo mal-definido.

Para evitar isso, algumas medidas muito simples podem ser adotadas, aqui vai uma lista de 10 dicas para serem usadas na hora de determinar o escopo de um projeto:

•Assegure-se de que todos sabem e entendem qual o objetivo do projeto e que haja consenso sobre o resultado final do mesmo;

•Ouça com atenção o que seu cliente descreve;

•Tente entender não o que ele lhe pede para fazer, mas sim o que ele precisa para resolver o problema que lhe apresenta;

•Descubra o que ele não quer. Muitas vezes um projeto não vai para frente por que o escopo foca em coisas que não deveriam estar lá;

•Estabeleça o que não vai ser feito no projeto enquanto o cliente ainda estiver disponível. Se ele pedir X e Y, mas você perceber que Z e W devem ser providenciados, mas somente W é da sua responsabilidade, deixe claro que Z está fora do escopo do projeto;

•Estabeleça o que será necessário para que o projeto seja atingido, defina os pressupostos, de forma que todos saibam de antemão quais as necessidades básicas do projeto antes que elas atrapalhem seu andamento;

•Seja realista quanto ao que pode ou não ser realizado, quanto mais “pé-no-chão” é o escopo, maior a chance de sucesso do projeto;

•Evite o GoldPlating. Se não faz parte do escopo do projeto, não adianta tentar agradar o cliente com aplicações/funções ‘firula’. Elas podem acabar acarretando em um atraso no cronograma;

•Não tenho medo nem pena de fazer perguntas. Pode parecer óbvio para você, mas se não estiver absolutamente claro, pergunte;

•Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunião quando o escopo for definido, assim qualquer problema técnico ou dúvida operacional poderá ser sanada na hora, em vez de descoberta posteriormente, causando problemas para o projeto.

Isso não cobre todas as coisas que se pode fazer para assegurar um escopo coerente, realista e dentro das expectativas do cliente, mas deve minimizar a quantidade de problemas que costumam ocorrer durante a elaboração do mesmo. Usar templates também pode ser uma boa idéia, já que elas facilitam a visualização do conteúdo e servem como guia para o que deve ser observado no processo de definição do escopo.

É isso, boa sorte com seus projetos!

GoldPlating: A adição de funções e/ou entregas num projeto que não foram requisitadas. O GoldPlating costuma desviar as atividades de seu foco e comumente leva ao temido ScopeCreep.

fonte:papogp.wordpress.com