Por que as Lições Aprendidas raramente mudam o próximo projeto

Todo projeto termina com uma lista. O que funcionou, o que deu errado, o que faríamos diferente. A lista é arquivada. O próximo projeto começa e, mais do que as equipes admitem, comete os mesmos erros novamente.

O problema raramente é o registro. É a distância entre uma lição identificada e uma lição aplicada. Um dos programas de lições aprendidas mais documentados do mundo, o da NASA, mediu essa distância. Suas constatações vêm primeiro. Um pequeno ciclo que reduz essa distância vem depois.

Identificar não é o mesmo que aprender

Uma lição é identificada quando alguém a escreve. Ela é aprendida quando a organização passa a se comportar de forma diferente por causa dela. Entre as duas, existe um grande volume de trabalho que a maioria dos processos de lições aprendidas nunca atribui a ninguém.

Pesquisas sobre organizações de projetos nomeiam o padrão diretamente. No International Journal of Project Management, Duffield e Whitty descobriram que os processos de lições aprendidas raramente acontecem e, quando ocorrem, focam na "identificação de lições em vez do aprendizado organizacional". O resultado é um documento. O objetivo pretendido é uma mudança na forma como a próxima equipe trabalha. São coisas diferentes, e apenas uma delas é fácil de produzir.

O que as próprias auditorias da NASA descobriram

A NASA leva as lições a sério. Ela opera o Lessons Learned Information System (LLIS), e sua exigência de procedimento NPR 7120.6, o Lessons Learned Process, define como as lições são coletadas, validadas, avaliadas e codificadas. Isso torna suas auditorias um caso de teste útil. Se as lições travam ali, a causa não é a falta de intenção.

Em 2001, o U.S. General Accounting Office (agora Government Accountability Office) pesquisou gerentes de programas e projetos da NASA. Dos 115 que responderam:

• 27% não tinham conhecimento do LLIS antes da pesquisa.
• 17,5% aplicaram uma lição que encontraram através do LLIS.
• 58% disseram que os sistemas atuais não permitiam recuperar as lições certas no momento certo.

O GAO concluiu que "as lições não são rotineiramente identificadas, coletadas ou compartilhadas". O aprendizado acontecia, mas principalmente por meio de revisões e conversas com colegas, não pelo sistema construído para isso.

Em 2012, o Office of Inspector General da NASA voltou ao questionamento. Eles pesquisaram 28 projetos de ciência e voos espaciais lançados entre 2005 e 2011. Dezesseis gerentes de projeto disseram que usavam o LLIS, e apenas seis deles o acharam útil. Doze haviam contribuído com lições. Apenas dez conheciam a obrigatoriedade de contribuir. Os gerentes descreveram o sistema como desatualizado e difícil de pesquisar, e muitos viam seus próprios projetos como únicos demais para que lições passadas fossem aplicáveis. O OIG também descobriu que apenas dois centros da NASA cumpriam totalmente a NPR 7120.6 na condução de seus próprios processos.

O padrão é consistente ao longo de onze anos. As lições eram armazenadas. Poucas eram recuperadas. Ainda menos mudavam o trabalho.

Por que as lições travam

Ao ler as auditorias atentamente, três causas retornam constantemente. Elas se aplicam muito além dos voos espaciais.

• As lições são escritas como histórias, não como instruções. Um parágrafo sobre o que aconteceu é difícil de transformar em ação. Ele não diz qual documento, etapa ou decisão deve ser diferente agora.
• As lições vivem separadas do trabalho. Um banco de dados separado exige que pessoas ocupadas saiam à procura. A maioria não o fará, especialmente sob pressão de cronograma. O GAO descobriu que os gerentes aprendiam mais com colegas e revisões do que com o sistema.
• Ninguém verifica. O registro é contabilizado. A aplicação, não. Quando a única métrica é quantas lições foram registradas, as equipes tornam-se especialistas em registrar.

Nenhum desses é apenas um problema de tecnologia. Cada um é um elo perdido: entre a lição e o que ela deve mudar, e entre essa mudança e as evidências de que ela ocorreu.

Pause and Learn: aprendendo enquanto o projeto ainda está em execução

O NASA Goddard Space Flight Center respondeu parte disso com uma prática chamada Pause and Learn. Em vez de esperar por uma revisão de encerramento, a equipe do projeto faz uma pausa em pontos significativos do ciclo de vida para refletir em conjunto.

Conforme descrito por Edward Rogers e Barbara Fillip, uma sessão padrão reúne de 10 a 20 pessoas de uma equipe de projeto por cerca de 90 minutos. Ela aborda quatro ou cinco tópicos escolhidos antecipadamente e trabalha com três perguntas: o que correu bem, o que não funcionou e o que faríamos de diferente. As regras básicas são lidas em todas as sessões. A discussão é registrada como um mapa de conhecimento, revisada com o gerente de projeto e compartilhada em workshops posteriores. As sessões são planejadas no plano de lições aprendidas do projeto, e não convocadas apenas quando algo falha.

O Pause and Learn acerta em dois pontos. Ele captura as lições enquanto a memória está fresca. E mantém a conversa dentro da equipe que irá agir sobre ela. O que ele não faz por conta própria é garantir que o próximo projeto adote a lição. Para isso, é necessário mais um passo.

Um processo de lições aprendidas que fecha o ciclo

A norma internacional para sistemas de gestão do conhecimento, ISO 30401, estabelece requisitos para estabelecer, implementar, manter, revisar e melhorar um sistema de gestão do conhecimento. O NIST Baldrige Excellence Framework pergunta, no item 4.2, como você constrói e gerencia o conhecimento organizacional, como compartilha as melhores práticas e como usa seu conhecimento para integrar o aprendizado à forma como sua organização opera. Ambos apontam para a mesma ideia: o conhecimento tem um ciclo de vida, e o registro é apenas sua primeira etapa.

Na prática, um ciclo de trabalho possui três etapas.

1. Registre em quatro campos. Para cada lição, escreva o que você esperava, o que realmente aconteceu, por que a lacuna ocorreu e o que você mudará. O último campo é o que importa. Se uma equipe não consegue nomear uma mudança, ela tem uma observação, não uma lição.

2. Vincule a lição ao seu alvo. Cada lição deve apontar para o procedimento, checklist, modelo ou decisão que ela altera. Atualize esse documento e registre o link. Agora a lição vive onde a próxima equipe trabalhará, não em uma pasta que eles precisam lembrar de abrir.

3. Verifique se o próximo projeto a aplicou. Quando um projeto posterior atingir a etapa afetada pela lição, confirme se o procedimento atualizado foi utilizado. Se foi, a lição foi aplicada. Se não foi, descubra o porquê. Talvez a mudança não tenha sido clara ou a etapa tenha sido pulada. Essa constatação é, por si só, uma lição, e retorna ao passo um.

Nossa regra na Roadyom é prova antes de afirmação. Para lições, isso significa que nada conta como aprendido até que um trabalho posterior o demonstre. Portanto, meça o ciclo pelo seu último passo. Um indicador útil é simples: das lições registradas no ano passado, quantas estão vinculadas a um procedimento e quantas delas foram aplicadas por um projeto posterior? Esse número é mais difícil de aumentar do que uma contagem de lições registradas. É também o único que diz se você está realmente aprendendo.

Uma lição que não nomeia uma mudança é uma observação. Uma mudança que nenhum passo posterior utiliza é um rascunho.

Como o Prism executa este ciclo

Prism mantém as decisões e o conhecimento de uma organização como etapas do próprio trabalho. Uma equipe pode abrir um registro de Pause and Learn em qualquer etapa, capturar o que era esperado, o que aconteceu, o porquê e o que muda, e vincular cada lição ao procedimento que ela deve atualizar. O Prism considera uma lição como integrada apenas quando ela está vinculada a um procedimento e um passo posterior a aplicou. Até lá, ela permanece visível como aberta. As pessoas decidem o que mudar; o Prism mantém o registro de se a mudança se manteve.

Fontes

1. Survey of NASA’s Lessons Learned Process (GAO-01-1015R). U.S. General Accounting Office (agora Government Accountability Office), 2001.
2. Review of NASA’s Lessons Learned Information System (IG-12-012). NASA Office of Inspector General, 2012.
3. Mapping Lessons Learned to Improve Contextual Learning at NASA. NASA Goddard Space Flight Center (E. W. Rogers, B. Fillip), NASA Technical Reports Server, 2016.
4. Developing a systemic lessons learned knowledge model for organisational learning through projects. International Journal of Project Management 33(2) (S. Duffield, S. J. Whitty), 2015.
5. ISO 30401:2018 Knowledge management systems — Requirements. International Organization for Standardization, 2018.
6. Baldrige Excellence Builder 2021–2022 (Item 4.2, Information and Knowledge Management). NIST Baldrige Performance Excellence Program, 2021.

Comentários

Seu nomeSeu comentário

Os comentários aparecem após a leitura da nossa equipe. Por favor, não inclua dados pessoais de pacientes ou colegas.

Publicar comentário