Gerência de Projetos

Ξ 1 comentário

Lições Aprendidas de um Projeto Mal Sucedido – Ganhador do Prêmio Viscode de Mauá – PMICE

publicado por Helio Ferenhof

LIÇÕES APRENDIDAS DE UM PROJETO MAL SUCEDIDO

 

Helio Aisenberg Ferenhof, MSc, MBA, PMP.[1]

Prof. do SENAC/SC; Pesquisador NGS/UFSC;

Fernando Antonio Forcellini, Dr.[2] 

 Prof. do Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento – PPGEGC/UFSC;

 

RESUMO

O presente estudo visa abordar questões relacionadas ao processo de lições aprendidas em projetos, tendo como foco de análise a gestão do conhecimento. O ponto de partida constituiu da seguinte questão: Por que alguns projetos fracassam e outros atingem o sucesso?  A partir disso, iniciou-se a busca científica para responder esta indagação, por intermédio da busca sistemática de literatura e um estudo de caso. Assim, este estudo considerou 9 artigos publicados em revistas e journals científicos, que apresentam estudos empíricos em gestão de projetos, gestão do conhecimento, lições aprendidas e fracasso, encontrados nas bases de dados Scopus. Este estudo aponta: a necessidade de comprometimento dos stakeholders com o projeto, e de se estabelecer um processo de lições aprendidas. Através deste, pode-se adquirir uma melhor compreensão das atividades envolvidas; identificar a causa raiz de sucessos e fracassos, ajudando a melhoria do processo; e ter o aumento sistemático das competências dos envolvidos.
Palavras-Chave: Processo de Lições Aprendidas, Gestão do Conhecimento, Gerenciamento de Projeto.

1. INTRODUÇÃO

Em projetos se espera sempre alcançar sucesso, afinal quem tem a intensão de investir tempo, recursos humanos e financeiros em esforços para criação de bens e serviços que não obtenham resultados positivos? Entretanto nem sempre os resultados destes esforços são bem sucedidos, projetos mal sucedidos também ocorrem por diversos fatores, mas o que pode ser feito para que o sucesso se repita e o fracasso não? Aprender com o que ocorreu é um caminho para responder esta indagação, o que deve ser feito ao longo de todo o ciclo de vida do projeto. Este aprendizado se dá pelo processo de gerar lições aprendidas que visa coletar dados e disseminá-los pela organização com intuito de contribuir para melhorar o planejamento, execução, monitoramento e controle dos projetos.

O presente artigo aborda questões relacionadas com o processo de lições aprendidas em projetos, tendo como foco de análise a gestão do conhecimento, utilizando como base um estudo de casos em um projeto mal sucedido. O ponto de partida constituiu da seguinte questão:  Por que alguns projetos fracassam e outros atingem o sucesso? A partir disso, iniciou-se a busca científica para responder esta interrogação, utilizando-se da busca sistemática de literatura, culminando na apresentação da importância do comprometimento dos stakeholders com o projeto e de se estabelecer um processo de gerar lições aprendidas ao longo de todo o projeto, gerando uma base de conhecimento.

2. PROCEDIMENTOS METODOLÓGICOS

Partido da pergunta norteadora: “Por que alguns projetos fracassam e outros atingem o sucesso?” Para que se respondesse a interrogação, foi considerado oportuno adotar como estratégia de pesquisa o estudo de caso qualitativo, o qual é indicado em investigações que buscam responder a este tipo de questão (Yin, 2009) bem como uma busca sistemática de literatura para dar suporte ao estudo de casos.

Os descritores aplicados na busca sistemática foram: “Knowledge Management”, “Lessons Learned”, Project Management”, “Failure. Ainda, para a coleta de dados seguiu-se os seguintes critérios de inclusão e exclusão:

  1. Artigos que trazem a relação entre gerenciamento de projetos, conhecimento e lições aprendidas;

O procedimento de localizar e selecionar os estudos potenciais nas bases de dados Scopus foi:

a) Seleção de artigos que contenham ou no título, ou no resumo, ou nas palavras-chave do artigo, os descritores definidos;
b) Busca por tipo de documento: article;
c) Seleção de artigos disponíveis e que contenham texto na íntegra;
d) Realização de nova triagem, conforme os critérios de inclusão.

De acordo com a Colaboração Cochrane (CLARKE et al., 2000), indica que as etapas para se fazer um revisão sistemática são: de planejamento, execução, análise e relatoria. Sendo assim, o presente estudo respeitou todos estas etapas.

É possível identificar, avaliar e interpretar por intermédio da revisão sistemática: o que fora pesquisado de antemão; o que é relevante; e, o que está disponível nas bases de dados. Agrupando de forma organizada resultados de pesquisas prévias auxiliando no esclarecimento de diferenças encontradas entre estudos primários que investigam a mesma questão (KITCHENHAM, 2004).

A base Scopus foi escolhida, pois esta permite “uma visão multidisciplinar e integrada de fontes relevantes para a pesquisa bibliográfica sistemática” (FREIRE, 2010).

A procura foi executada utilizando os descritores: knowledge management, project management, lessons learned e failure por intermédio da query TITLE-ABS-KEY(“knowledge management” AND “lessons learned” AND “project management” AND failure) AND DOCTYPE(ar) obtendo o retorno de 9 documentos. Os mesmos, foram analisados para construção dos resultados. Assim, a abordagem metodológica adotada caracteriza-se como um estudo exploratório e descritivo, feito mediante a busca sistemática da literatura.

Para fins de confiabilidade e repetibilidade do método, os autores do presente estudo informam que as buscas foram efetuadas na data 12/04/2011. Novos documentos podem aparecer nas futuras buscas, por serem inseridos na base após a data da busca.

3. LIÇÕES APRENDIDAS?

Lições aprendidas são um processo, um meio de explicitar experiências, ou seja, conhecimento. Desenvolvê-las se da por intermédio do compartilhamento destas experiências no projeto e entre projetos. O intuito é aumentar assim a satisfação com o trabalho, melhorando a inter-relação entre os participantes do processo, contribuindo para o aprendizado destes e para o aprendizado organizacional (Baaz et al., 2010).

Ferenhof et al (2011) relatam que do ponto de vista da Gestão do Conhecimento(GC), toda e qualquer experiência é conhecimento. Sendo necessário, ser explicitado, compartilhado e disseminado para agregar valor as pessoas e organizações. Para estes autores, o meio para agregar este valor é executar o processo de lições aprendidas.

De acordo com Schindler e Eppler (2003) o processo de lições aprendidas deve se feito de forma sistemática permitindo que à organização compare seus distintos projetos mais metodicamente e assim documentar o seu mecanismo mais eficaz de resolução de problemas. Esta documentação sistemática de percalços, erros, falhas ou potenciais armadilhas, ajuda a mitigar riscos do projeto e projetos futuros. Os autores apontam ainda, que as lições aprendidas devem ser uma revisão periódica durante todo o ciclo de vida do projeto. O que leva a algumas vantagens: os eventos de sucesso e falha são mais recentes, facilitando o aprendizado dos envolvidos bem como o organizacional. Evitando assim um possível esquecimento quando o processo é feito ao término do projeto; ao longo do projeto é mais fácil reunir toda a equipe do que após o encerramento, onde muitas vezes os membros são alocados em outros projetos ou tarefas operacionais e sua agenda não está mais a disposição do projeto que tem questões à serem aprendidas.

Corroborando, Decker et al. (2005) descreve algumas outras vantagens de ter um processo de lições aprendidas formalmente estabelecido, sendo estas:

a) um consenso sobre um processo é construído;
b) problemas durante a execução de um processo são resolvidos de forma colaborativa e capturados como lições aprendidas, para facilitar as execuções do próximo processo.
c) modelos de processo são revistos para uma melhor inteligibilidade e outros aspectos de qualidade;

Huemann e Anbari (2007) reforçam o fato das lições aprendidas serem uma investigação sistemática levando em conta os processos e a gestão técnica, bem como critérios de desempenho de ambos. As lições aprendias ajudam a identificar as causas raiz de sucesso ou fracasso e ainda, destaca melhorias e oportunidades.

Ao se estabelecer um processo formal de lições aprendidas, espera-se identificar, explicitar, compartilhar conhecimento, transformando as experiencias pessoais em conhecimento organizacional. Para isto, este estudo recomenda a utilização do processo de conversão do conhecimento proposto por Nonaka e Takeuchi (1997)  que o faz por intermédio da socialização, externalização, combinação e internalização do conhecimento. Anbari et al (2008) ressaltam que devem fazer parte do processo de lições aprendidas as experiências boas, ruins e feias dos projetos. Se aprende tanto com o sucesso quanto com o fracasso.

4. SUCESSO E FRACASSO?

O guia de melhores práticas em gerenciamento de projetos PMBOK®, guia este, escrito, revisado e seguido por diversos gerentes de projetos no mundo inteiro, define sucesso em projetos como sendo o processo de outorgar todos os entregáveis, conforme os planos de projetos, principalmente em relação a tempo, custo, escopo e qualidade PMBOK®(2008). Na mesma linha de raciocínio, KERZNER(2002, p.44) aponta que sucesso é mensurado em termos de fatores primários e secundários, sendo eles os primários: no prazo; dentro do orçamento; no nível desejado de qualidade e secundários: aceitação pelo cliente; o cliente concorda com a utilização de seu nome como referência.

O fracasso, é inversamente proporcional ao sucesso. Sendo assim, para que ocorra o fracasso em projetos basta que um dos fatores não sejam entregues conforme o seu respectivo planejamento seja em tempo, custo, escopo ou qualidade.

Para melhor demostrar os fatores que levam ao sucesso e fracasso em projetos, este estudo recorre ao relatório publicado pelo The Standish Group (1994), chamado o relatório do caos que aponta três categorias de projetos: sucesso, que foram completados no tempo e orçamento, com todas as características e funções, conforme especificado; contestados, foram concluídos, mas excederam o  custo, tempo, e / ou falta de características e funções que foram originalmente especificadas e; fracasso, Estes foram abandonados ou cancelados em algum ponto e tornou-se assim perda total. O The Standish Group(1994) ainda aponta, os fatores mais encontrados em cada uma das categorias. O quadro 1 aponta as cinco principais características de cada uma das três categorias.

Quadro 1 – Principais características de Projetos com Sucesso, Contestados e Fracassos.

SucessoContestadosFracassados

1. Envolvimento do Usuário

1. A falta de participação do usuário

1. Requisitos incompletos

2. Apoio da Alta Gestão

2. Requisitos e especificações incompletos

2. Falta de envolvimento do usuário

3. Declaração de Requisitos Claros

3. Mudanças nos requisitos e especificações

3. Falta de recursos

4. Planejamento Apropriado

4. Falta de Apoio Executivo

4. Expectativas irrealistas

5. Expectativas Realistas

5. Incompetência técnica

5. Falta de Apoio Executivo

Fonte: Autores. Dados de pesquisa: Adaptado de The Standish Group (1994).

Observa-se que nos três primeiros lugares para cada categoria, o envolvimento do usuário é listado como o primeiro ou o segundo em cada um.

5. ESTUDO DE CASO

Em uma empresa multinacional da indústria óptica (líder em seu segmento) um projeto denominado Pedido Eletrônico que fora criado pelo vice-presidente e diretor de operações da empresa ao qual tinha como objetivo receber os pedidos de lentes e blocos através da internet. O intuito do projeto era que com a entrada dos pedidos via internet, haveria uma redução dos pedidos via telefone e fax, reduzindo assim a digitação e por sua vez erros de digitação pelos operadores, bem como o de insumos para a impressão de fax. Outro ponto considerado foi a diminuição do tempo de atendimento e entrada dos pedidos, uma vez que os mesmos seriam enviados diretamente pelo cliente, dispensando a utilização de um operador. Finalmente, redução no número de operadores de telemarketing de acordo com o aumento dos pedidos eletrônicos.

Suas premissas baseavam-se na ideia de que os clientes passariam a utilizar cada vez mais o pedido eletrônico, em vez de pedidos via fax ou telefone. Os gerentes comerciais e regionais da empresa utilizariam o sistema para aprovação do pedido. E o projeto possuía como restrição que os clientes e gerentes comerciais necessitariam de um computador conectado a internet.

O Pedido Eletrônico tinha como escopo:

  • Receber os pedidos em “grade” (Matriz de pedidos: Produto, Base, Quantidade) via internet;
  • A inclusão de desconto e prazo previamente negociado por cliente e por produto;
  • A aprovação do pedido por um gerente comercial;
  • O gerente comercial poder modificar o percentual de desconto na hora da aprovação;
  • Uma segunda aprovação do pedido por um gerente regional dependendo do valor do desconto ou da compra;
  • Ambas as aprovações seriam feitas na extranet da empresa e;
  • A entrada efetiva do pedido no ERP da empresa.

Entende-se por extranet como sendo uma rede privada que se utiliza da internet para compartilhar de forma segura informações ou operações de negócios com clientes, fornecedores, parceiros, representantes ou outro grupo de interesse (Korper e Ellis, 2001). E, ERP como um sistema de informação computacional que integra todos os dados e processos de uma empresa em um único sistema (Laudon, 2004; Padoveze, 2004).

6. RESULTADOS E DISCUSSÃO

O projeto Pedido Eletrônico estava caminhando muito bem, dentro do custo, prazo, qualidade e a equipe de projeto motivada. Houve levantamento dos requisitos do mesmo, análise e desenvolvimento de toda a parte de entrada do pedido, mas quando se chegou na hora de definição de uma regra de negócios para o prazo, desconto e a aprovação do pedido é que houve a grande surpresa. A diretoria comercial não tinha uma regra de negócio definida, e não tinha o mínimo interesse em definir um padrão, pois gerentes comerciais de mesmo nível tinham condições de pagamento e desconto diferenciados uns dos outros e um não poderia, de maneira alguma, tomar conhecimento de que o seu colega tinha este privilégio. Logo, como gerar uma regra de negócio que atenda a todos, sem o interesse da alta gerencia comercial? Pela identificação desta falta de interesse e comprometimento da área comercial em normatizar as regras de negócio, apontadas pelo gerente de projetos ao sponsor, o mesmo resolveu cancelar o projeto, adiando a “briga” pela definição esta regra. Tendo como base o portfolio de projetos que previa a migração do ERP utilizado pela empresa para outro, devido a aquisição da empresa que desenvolveu o ERP instalado por outra fabricante de software maior. Fato este que ocorreu durante o desenvolvimento do projeto Pedido Eletrônico.

Ao se executar o processo de lições aprendidas do projeto Pedido Eletrônico, se identificou e registrou na base de conhecimentos da empresa que a falta de comprometimento dos stakeholders pode ser destrutiva ao projeto. Ao se comparar e analisar os resultados obtidos pela busca sistemática de literatura sobre o tema sucesso e fracasso em projetos com os obtidos no projeto Pedido Eletrônico, constata-se que o envolvimento e o comprometimento dos stakeholders é fator fundamental para o sucesso de projetos.

Para evitar esta falha em projetos futuros, a devida identificação e gestão dos stakeholders deve ser feita. Fato este ressaltado pelo PMBOK®(2008) que traz estes dois processos como sendo fatores críticos de sucesso de projetos. Para ele a identificação das partes interessadas, stakeholders, deve ser feita desde o início do projeto. De forma a analisar o nível de interesse, expectativas, importâncias e influências destes no projeto.  O mesmo ainda aponta que após a identificação, uma estratégia de como lidar com estes interessados deve ser traçada. De modo que haja uma interação com os stakeholders que atenda as suas necessidades e solucione questões a medida que estas ocorrem.

7. CONSIDERAÇÕES FINAIS

Observou-se pelo estudo de casos que o comprometimento dos stakeholders é fundamental para o sucesso em projetos e que é essencial divulgar experiências de gerenciamento de projetos por intermédio de lições aprendidas dentro de uma organização para evitar a repetição dos mesmos erros, e repetir os acertos. Ter uma base de conhecimento organizacional é de extrema valia para que o conhecimento seja armazenado e recuperado de forma adequada, isto é, de uma maneira que seja de fácil acesso, identificação, compreensão, e recuperação do conhecimento necessário em relação a um fato ou situação, seja para resolver uma situação ou que contenha as experiências de sucesso à serem repetidas. Para facilitar a disseminação destes conhecimentos, recomenda-se seguir o processo de conversão do conhecimento proposto por Nonaka e Takeuchi (1997).

O comprometimento com o processo de lições aprendidas é essencial para que os conhecimentos fluam dentro da organização sendo assim, deve se considerar uma abordagem middle-up-down que engloba todos os níveis hierárquicos de uma empresa. Nonaka e Takeuchi (1997) apontam que este modelo de gestão a criação de conhecimento que advêm da liderança dos gerentes de nível médio, por intermédio de um processo em espiral de conversão que envolve tanto a alta gerência quanto o nível operacional. Este processo faz com que as ideias ou visão da alta gerencia, suas estratégias, fluam com mais facilidade pois, a gerência de nível médio desenvolve conceitos mais concretos e os traduzem a uma linguagem que seja de mais fácil compreensão e implementação pelos níveis operacionais. Sendo assim, a organização como um todo deve estar comprometida com o processo, não apenas o gerente de projetos e/ou sua equipe, quando fazem parte de um projeto, mas sim em todas as tarefas diárias.

8. REFERÊNCIAS

ANBARI F. T., CARAYANNISB E. G., VOETSCH R. J.; Post-project reviews as a key project management competence Technovation, v. 28, n. 10, p. 633-643. doi:10.1016/j.technovation.2007.12.001,  2008.

BAAZ, A.; AB, E.; HOLMBERG, L.; SANDBERG, A. B.; AB, E. lessons learned Appreciating Lessons Learned. IEEE Software 27(4): 72-79. 2010.

BUSBY, J.S., An assessment of post-project reviews. Project Management Journal 30 (3), 23–29, 1999.

CLARKE M, OXMAN AD, EDITORS. Cochrane Reviewers’ Handbook 4.1 [updated June 2000]. In: Review Manager (RevMan) [Computer program]. Version 4.1. Oxford, England: The Cochrane Collaboration, 2000.

CLELAND, D.I., A strategy for ongoing project evaluation. Project Management Journal XVI (3), 11–17, 1985.

DECKER B., RECH J., ALTHOFF K.D., KLOTZ A., LEOPOLD E, VOSS A.; eParticipative Process Learning––process-oriented experience management and conflict solving. Data & Knowledge Engineering, v. 52, n. 1, p. 5-31. doi: 10.1016/j.datak.2004.06.006, 2005.

Comité Européen de Normalisation (CEN), “European Guide to good Practice in Knowledge Management CWA 14924”, 2004 Disponível em: ftp://cenftp1.cenorm.be/PUBLIC/CWAs/e-Europe/KM/CWA14924-04-2004-Mar.pdf. Acessado em 30/09/2010.

FERENHOF, H. A. ; FORCELLINI, F. A. ; VARVAKIS, G. . Lições Aprendidas: Agregando Valor ao Gerenciamento de Projetos. Florianópolis. Anais da Conferência Internacional de Gerenciamento de Projetos – PMI/SC, 2011.

FREIRE, P. S. Compartilhamento de conhecimento interorganizacional: causas essenciais dos problemas de integração em fusões e aquisições (F&A). 2010. 148f. Dissertação (Mestrado em Engenharia e Gestão do Conhecimento) – Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento, Universidade Federal de Santa Catarina – UFSC. Florianópolis, 2010.

GRUBER, T.R. A translation approach to portable ontology specifications, Knowledge Acquisition 199–220, 1993.

HUEMANN,M., ANBARI, F.T., Project auditing: a tool for compliance, governance, empowerment, and improvement. Journal of Academy of Business and Economics (in press), 2007.

KAMSUFOGUEM, B.; COUDERT, T.; BELER, C.; GENESTE, L. Knowledge formalization in experience feedback processes: An ontology-based approach. Computers in Industry, v. 59, n. 7, p. 694-710. doi: 10.1016/j.compind.2007.12.014, 2008.

KERZNER, Harold. Gestão de projetos: as melhores práticas. Porto Alegre: Bookman, 2002. 519p.

KITCHENHAM, B. Procedures for Performing Systematic Reviews. Joint Technical Report Software Engineering Group, Department of Computer Science Keele University, United King and Empirical Software Engineering, National ICT Australia Ltd, Australia. 2004.

KORPER, S.; ELLIS, J. E-Commerce book: building the e-empire. 2. ed. San Diego: Academic Press, 2001. 299p.

LAUDON, Kenneth C. Sistemas de Informações gerenciais : administrando a empresa digital. São Paulo: Prentice Hall, 2004

NONAKA, I.; TACKEUCHI, H. Criação do Conhecimento na Empresa: como as empresas japonesas geram a dinâmica da inovação. 19ª. Ed. Rio de Janeiro: Elsevier, 1997.

OECD. Manual de Oslo, 3ª Edição – 2005 – Tradução FINEP 2006.

PADOVOZE, Clóvis Luís. Sistemas de informações contábeis: fundamentos e análise. São Paulo: Atlas, 2004

PESZYNSKI, K., COOPER, V. and MOLLA, A., Developing a Knowledge Management Strategy: Reflections from an Action Research Project. RMIT University, GPO Box 2476V, Melbourne, VIC, 3001, Austrália, 2008.

PROJECT MANAGEMENT INSTITUTE, PMI. Um Guia do Conjunto de Conhecimentos em Gerenciamentos de Projetos: Guia PMBOK. 4ed. Pennsylvania: Four Campus Boulevard, 2008.

SCHINDLER M., EPPLER M. J. Harvesting project knowledge: a review of project learning methods and success factors International Journal of Project Management, v. 21, p. 219-228, 2003.

SCHREIBER G., AKKERMANS H., ANJEWIERDEN A., HOOG R.D., SHADBOLT N., VELDE W.V.D., WIELINGA B., Knowledge Engineering and Management, The MIT Press, Cam- bridge, 2000.

THE STANDISH GROUP(1994). The chaos report. http://www.standishgroup.com/sample_research/chaos_1994_1.php. visualizado em 16 de setembro de 2009.

WILLIAMS, T., How do organizations learn from projects? In: Proceedings of PMI Research Conference [CD], Montreal, Canada, Project Management Institute, Newtown Square, PA, 2006.

YIN, R. K. Case Study Research: Design and Methods. Sage Publications, Inc, 2009.

[1] helio@prof.sc.senac.br

[2] forcellini@deps.ufsc.br

Artigo Ganhador do Prémio Viscode de Mauá 2011 – PMICE

Referência para Citação do Artigo no Formato ABNT:

FERENHOF, H. A. ; FORCELLINI, F. A. . LIÇÕES APRENDIDAS DE UM PROJETO MAL SUCEDIDO. In: VI Congresso Brasileiro de Gerenciamento de Projetos do PMI, 2011, Fortaleza. Anais VI Congresso Brasileiro de Gerenciamento de Projetos do PMI, 2011.

Autor

Helio Ferenhof, Dr. Eng, MBA, PMP .'. ITIL Foundations Bacharel em ciência da computação pela UNESA; Mestre em Engenharia e Gestão do Conhecimento – UFSC. Doutor em Engenharia de Produção e Sistemas – UFSC. MBA em E-Business pela FGV/RJ; Professor da Pós-Graduação em Gerenciamento de Projetos e Segurança da Informação do SENAC/SC; Professor da Pós-Graduação em Gerenciamento de TI & Projetos da Universidade Estácio de Sá /SC; Diretor do IGCI empresa de consultoria em Gestão do Conhecimento, Gestão de Projetos & TI (www.igci.com.br) ; Apresenta mais de 20 anos de experiência adquirida em empresas multinacionais e consultorias de renome.

Helio Ferenhof

Comentários

You must be logged in to post a comment.

Busca

Patrocínio

Publicidade



Siga-nos!

Newsletter: Inscreva-se

Para se inscrever em nossa newsletter preencha o formulário.

Artigos Recentes