- O elemento humano nas falhas de projetos
- Cultura organizacional.
Apesar da imagem externa da maioria das organizações seja de um ambiente de sinergia e parceria entre as pessoas, a realidade pode ser bem diferente. Ao contrario de terem uma estrutura balanceada, com funções organizacionais com igualdade de prioridade, é sabido que na maioria das organizações certar áreas de comando exercem um status maior que outras - uma “hierarquia não-documentada” em outras palavras.
- Pressões internas para respeitar os deliverables.
Muitos Diretores e Gerentes de tecnologia freqüentemente se queixam de que nunca têm tempo suficiente para implementar com eficiência as estratégias traçadas pelos executivos seniores.
A falta de representatividade da área de TI deve contribuir com este problema.
- Resistência a mudanças.
Todos nós gostaríamos de estar em uma posição em que agradamos a todos o tempo todo, porém as circunstancias freqüentemente nos leva ao inverso. Projetos de TI têm a capacidade de trazer benefícios substanciais às empresas, mas freqüentemente isso é feito com algum custo para aqueles que estão trabalhando nele. Para a maioria dos usuários, projetos de TI não trazem benefícios, na verdade o oposto. De fato a introdução de novos sistemas podem disparar excessos e moral baixa assim como novas praticas de trabalho forçadas (como o uso de sistemas de gravação de tempos).
- Egomania.
Estou certo de que não sou a única pessoa a ter testemunhado um individuo, em uma posição de autoridade, direcionar um projeto diretamente ao abandono, descartando os conselhos dos outros, com o objetivo de alcançar suas próprias metas. Quando a chegada à data da implementação se torna a única prioridade, pessoas que se tornam um obstáculo ou não conseguem seguir o ritmo de trabalho tendem a ser as mais sacrificadas. De forma que esta abordagem pode ser eficiente para problemas pontuais e de grandes proporções, porém estas situações em longo prazo somente alienam as pessoas. Uma vez escolhido manter-se dentro da empresa, estes indivíduos irão freqüentemente se distanciar de qualquer projeto desta natureza no futuro.
- Pobre Baixa performance dos times de projeto.
Não é o único objetivo de um gerenciamento de projeto introduzir termos e abreviações como “BCWS”, “total flutuante” ou “lag” no vocabulário de negócios. Gerenciamento de projetos foca-se nas pessoas. Uma visão geral do plano do projeto é como, de certa maneira, identificar as atividades chave e suas dependências para se obter os milestones, mas tão impactante quanto isso, é a omissão do treinamento baseado nas competências e as praticas de formação de times. As chances de que o plano irá também identificar oportunidades de coaching e mentoração serão bem menores.
- Causas chaves de fracassos em times de projetos
- Motivação arruinada.
- Falta de controle dos problemas com os empregados.
- Pobres condições inadequadas de trabalho.
- Falta de treinamento e apoio.
- Adicionar tardiamente de desenvolvedores no projeto.
- O papel dos stakeholders no projeto.
- Análise dos Stakeholders.
- Estudo de caso: A bolsa de valores de Londres (projeto de Touro).
- O conflito dos Stakeholders.
- Resistência dos Stakeholders.
- Melhorando os aspectos humanos
- Promovendo uma efetiva comunicação efetiva.
- Reduzindo a cultura dae culpa.
- Construindo a essência do time de projeto.
- Treinando e mentoring.
- Estudo de caso: Companhia Z.
- Administração de Suprimentos
- Administrando o contrato.
- Os benefícios de administração de suprimentos.
- As causas de fracasso.
- Pessoas: Fatores críticos de sucesso.
No coração de todo projeto existe um processo que irá entregar um ou mais produtos da organização. Com os projetos IS, o processo é focado no desenvolvimento do software. O desenvolvimento de software é uma atividade fundamental em um projeto IS que habilita um jogo de exigências funcionais que devem ser conhecidas no desenvolvimento de um ou mais programas de computadores. Tipicamente, o processo de desenvolvimento de softwares em projetos IS será responsável pela produção de um dos seguintes produtos de software:
- - Softwares sistemas – Usado para controlar hardware de computadores e periféricos do computador;
- - Software militar – Tais como sistemas de guia de mísseis e sistemas de navegação;
- - Software comercial – Tais como marketing e sistemas de gerenciamento de compras.
Apesar da necessidade de produtos de desenvolvimento de software, a comunidade IS não tem uma boa trajetória com relação ao sucesso no desenvolvimento de software. Comparado com as taxas de falhas de projeto em outros setores industriais tais como construção e engenharia, a profissão IS tem muito a aprender.
De fato, o guru de desenvolvimento de softwares Capers Jones vem tentando quantificar o problema sugerindo que se a industria da construção tivesse a mesma taxa de projetos que falharam na industria de software, então em metade dos prédios de escritório do mundo mais de 30 andares seriam abandonados antes do término, a média de altura dos prédios da cidade de Nova York seria de somente 3 andares e não existiriam arranha-céus.
Uma das várias razões pela qual os projetos tiveram falhas no passado e continuarão com falhas no futuro é que o sucesso do projeto geralmente é mensurado somente pela habilidade do time de projeto em implementar e controlar os custos e prazos. Uma lógica progressiva deste argumento identifica uma situação onde o sucesso do projeto é a entrega de uma funcionalidade empresarial de qualidade indeterminada e que não exceda o orçamento ou o prazo.
Pode-se contemplar o que os usuários de um sistema de computador recentemente implementado sentem quando os stakeholders do projeto recebem gratificações substanciais por entregar um sistema que na visão deles é o melhor, não melhor que um sistema prévio, ou na pior das hipóteses, totalmente sem aplicabilidade. O que é mais preocupante, no entanto, é que apesar de muitos projetos não satisfazerem as necessidades fundamentais das empresas, o sucesso do projeto ainda é considerado referindo-se ao sistema como: o melhor, o mais barato, o mais rápido, o mais prestigioso, o de valor agregado, e negócio-crítico.
Para a qualidade ser um atributo significante, medidas objetivas devem ser utilizadas, contra a qual podem ser medidos os níveis desejados de qualidade.