Entenda como capturar, analisar, validar, armazenar e aplicar lições aprendidas em projetos de engenharia para transformar experiência em melhoria verificável.
Confira!
Projetos de engenharia produzem conhecimento continuamente. Decisões de projeto, interfaces críticas, falhas de coordenação, soluções de campo, respostas a riscos, desempenho de fornecedores, métodos construtivos, resultados de testes e estratégias de contratação geram informações que podem melhorar empreendimentos futuros. Entretanto, esse valor somente é preservado quando a experiência é convertida em conhecimento verificável, organizado e efetivamente reutilizado.
Uma reunião ao final do projeto, uma ata com opiniões ou uma pasta chamada “lições aprendidas” não constituem, por si sós, um sistema de aprendizagem. Para que uma lição seja útil, ela precisa apresentar contexto, evidência, análise, causa, consequência, recomendação, condições de aplicabilidade e um destino organizacional. Também deve ser recuperada no momento certo e incorporada a decisões, riscos, contratos, projetos, procedimentos ou padrões.
Este artigo apresenta um método para estruturar lições aprendidas em projetos de engenharia sem reduzir o processo a um ritual de encerramento. O foco está na captura durante o ciclo de vida, na condução das sessões, na análise das causas, na curadoria técnica, na arquitetura do repositório, na transformação das lições em ações e nos indicadores que demonstram se a organização realmente aprendeu.
O que são lições aprendidas e por que registrar não significa aprender
Lições aprendidas são conhecimentos derivados de experiências reais que ajudam a explicar como determinada situação foi tratada, quais resultados ocorreram e como situações semelhantes podem ser conduzidas no futuro. Elas podem resultar de sucessos, falhas, quase falhas, decisões técnicas, mudanças, riscos materializados, oportunidades aproveitadas ou soluções que produziram desempenho superior ao esperado.
A expressão deve ser utilizada com rigor. Um fato isolado não é necessariamente uma lição. A afirmação “o fornecedor atrasou” descreve um evento; “o projeto teve falhas de comunicação” apresenta uma avaliação genérica; e “precisamos planejar melhor” é uma recomendação vaga. Nenhuma dessas formulações explica suficientemente o contexto, as causas, os mecanismos de prevenção ou as condições em que a recomendação deve ser aplicada.
Registro, conhecimento e mudança organizacional
O registro preserva informação. A análise transforma informação em entendimento. A aplicação converte entendimento em ação. A verificação demonstra se a ação produziu melhoria. A organização somente pode afirmar que aprendeu quando o conhecimento alterou uma decisão, um comportamento, um processo, um requisito, um contrato, um padrão ou uma forma de controle.
A ISO 30401:2018 estabelece requisitos e orientações para sistemas de gestão do conhecimento aplicáveis a organizações de qualquer porte ou natureza. A página oficial da ISO indica que essa edição permanece publicada enquanto uma segunda edição está em desenvolvimento. Isso reforça uma distinção importante: gestão do conhecimento não é apenas tecnologia de armazenamento, mas um sistema organizacional que precisa ser estabelecido, mantido, avaliado e melhorado.
Lições positivas e negativas
O processo não deve concentrar-se apenas em erros. Soluções bem-sucedidas, métodos mais produtivos, decisões que evitaram riscos, formas eficazes de coordenação e estratégias de contratação que melhoraram resultados precisam ser identificadas. Caso contrário, a organização conhece seus problemas, mas não preserva práticas que merecem ser repetidas.
Também é inadequado transformar uma ocorrência negativa em busca por culpados. O objetivo é compreender condições, decisões, interfaces e controles. Responsabilidades podem precisar ser apuradas em processos próprios, mas a sessão de aprendizagem deve produzir conhecimento capaz de orientar o sistema.
Relação com não conformidades, riscos e mudanças
Uma não conformidade registra o descumprimento de requisito e seu tratamento. Um risco representa incerteza sobre objetivos. Uma mudança altera uma referência aprovada. Uma lição aprendida conecta essas ocorrências a um entendimento reutilizável. Os registros podem estar relacionados, mas possuem funções distintas.
A Gestão de Pendências, RFIs e Não Conformidades preserva o histórico operacional das ocorrências. A lição precisa avançar além do fechamento do item e responder por que a situação ocorreu, quais controles funcionaram ou falharam e o que deve mudar em projetos futuros.
Lição local e lição institucional
Nem toda observação precisa tornar-se regra corporativa. Algumas são específicas de um contrato, local, tecnologia, cliente ou condição operacional. Outras revelam padrões recorrentes e justificam mudanças em procedimentos, templates, critérios de contratação, bases de risco ou treinamento.
A curadoria deve classificar o alcance da lição. Uma recomendação pode ser aplicável somente a instalações energizadas, a contratos EPC, a projetos brownfield ou a fornecedores de determinada tecnologia. Sem esse contexto, a reutilização indiscriminada pode gerar decisões inadequadas.
| Elemento | Pergunta central | Exemplo em engenharia |
| fato | o que ocorreu? | desenho de interface foi emitido após a compra do equipamento |
| impacto | qual foi a consequência? | retrabalho, alteração de fabricação e atraso de montagem |
| causa | por que ocorreu? | dados do fornecedor não estavam vinculados ao cronograma de engenharia |
| resposta | como a equipe tratou? | revisão extraordinária e mudança da sequência de entrega |
| lição | o que deve orientar casos futuros? | submittals críticos precisam de marco contratual e integração à programação |
| ação organizacional | o que será alterado? | template de contrato, matriz de interfaces e checklist de liberação |
Registrar experiência não significa aprender.
A aprendizagem ocorre quando o conhecimento é validado, aplicado a uma decisão ou processo e produz resultado verificável.
Quando e como capturar lições durante o ciclo de vida do projeto
O PMI destaca que a captura não deve ser limitada ao encerramento. Projetos longos perdem profissionais, detalhes e contexto ao longo do tempo. Por isso, a aprendizagem deve ocorrer em momentos definidos e também imediatamente após eventos relevantes.
A ISO 21502:2020 apresenta orientações aplicáveis a diferentes tipos de projeto, portes, complexidades e abordagens de entrega. Em engenharia, o processo de aprendizagem deve acompanhar fases, marcos de decisão, pacotes, sistemas e contratos, mantendo vínculo com o ciclo real do empreendimento.
Início do projeto: recuperar antes de produzir
Um novo projeto deve começar pela consulta a experiências anteriores. A equipe precisa pesquisar lições relacionadas ao tipo de ativo, cliente, localização, tecnologia, regime contratual, interfaces, riscos e fornecedores. Essa consulta deve alimentar o planejamento, não aparecer apenas como referência documental.
Lições recuperadas podem modificar a EAP, a matriz de riscos, os critérios de contratação, o cronograma, a estratégia de revisão e os planos de inspeção. Uma base que não participa do início dos projetos funciona como arquivo histórico, não como sistema de decisão.
A NASA utiliza um sistema institucional de lições aprendidas e orienta suas equipes a consultar bases locais e corporativas durante o planejamento e ao longo do ciclo. O exemplo demonstra que recuperação é uma atividade ativa: o conhecimento precisa ser buscado antes que decisões equivalentes sejam repetidas.
Fases e marcos de decisão
FEL, Projeto Conceitual, FEED, Projeto Básico, Projeto Executivo, Procurement, Execução, Comissionamento e Operação Assistida produzem conhecimentos diferentes. Ao final de uma fase, a equipe deve avaliar premissas, qualidade das entradas, interfaces, desempenho dos processos e impactos sobre a etapa seguinte.
O Stage-Gate em Projetos de Engenharia pode incorporar a revisão de lições como parte do marco decisório. A fase seguinte deve receber não apenas entregáveis, mas também restrições, decisões, riscos e recomendações contextualizadas.
Eventos críticos e aprendizagem em tempo próximo
Falhas de teste, incidentes, mudanças significativas, atrasos relevantes, problemas de interface, pleitos, soluções inovadoras e decisões com grande efeito devem gerar análise enquanto o contexto está disponível. Esperar meses reduz a precisão e favorece narrativas simplificadas.
A captura próxima ao evento não significa publicar imediatamente uma conclusão. O registro preliminar preserva dados; a análise posterior verifica causas, evidências e aplicabilidade. Essa separação evita tanto a perda de memória quanto a disseminação de interpretações precipitadas.
Revisões periódicas
Projetos complexos podem realizar revisões mensais, trimestrais ou por pacote. O objetivo não é produzir grande quantidade de documentos, mas identificar padrões antes que se repitam em outras frentes. Ocorrências semelhantes em disciplinas diferentes podem revelar problema sistêmico de requisito, planejamento, contrato ou governança.
O Project Controls pode apoiar essa leitura por meio de tendências de prazo, custos, produtividade, mudanças e riscos. Indicadores mostram onde investigar; a lição explica mecanismos e orienta ações.
Encerramento e avaliação pós-projeto
No encerramento, a equipe consolida conhecimentos, revisa resultados, compara objetivos e identifica recomendações organizacionais. O conteúdo deve dialogar com o termo e o relatório final, mas possuir estrutura própria para reutilização.
A avaliação pós-projeto pode verificar benefícios e resultados que somente aparecem depois da transferência para operação. Uma solução aparentemente adequada durante a implantação pode produzir dificuldades de manutenção, desempenho ou disponibilidade. A aprendizagem precisa considerar o ciclo de vida do ativo.
| Momento | Objetivo da captura | Possível destino |
| planejamento | recuperar experiências relevantes | riscos, estratégia, contrato e plano do projeto |
| fim de fase | avaliar entradas, decisões e interfaces | gate, plano da fase seguinte e padrões de revisão |
| evento crítico | preservar contexto e evitar repetição imediata | ação corretiva, risco, mudança e alerta técnico |
| revisão periódica | identificar recorrência e tendência | melhoria de processo e escalonamento de governança |
| encerramento | consolidar resultados e recomendações | relatório final, repositório e plano de ação |
| pós-projeto | verificar benefícios e efeitos operacionais | gestão de ativos, padrões e novos investimentos |
A captura deve acompanhar todo o ciclo do projeto.
Fases, eventos críticos, revisões periódicas e avaliações pós-projeto produzem conhecimentos diferentes e complementares.
Como conduzir uma sessão de lições aprendidas com profundidade e segurança psicológica
A qualidade da sessão depende da preparação, da facilitação e da confiança dos participantes. Reuniões conduzidas como auditorias informais ou disputas de narrativa geram respostas defensivas. Reuniões sem estrutura produzem comentários genéricos e pouco utilizáveis.
Preparação baseada em evidências
O facilitador deve reunir cronogramas, mudanças, riscos, relatórios, medições, registros de qualidade, decisões, resultados de testes, indicadores e avaliações de fornecedores. Esses elementos ajudam a reconstruir fatos e reduzem dependência de memória seletiva.
A pauta deve ser organizada por fase, objetivo, sistema, contrato ou tema. Participantes precisam receber questões antes da reunião e ter possibilidade de registrar observações individualmente. Pessoas que deixaram a equipe podem contribuir por entrevista ou formulário estruturado.
Participantes e independência da facilitação
A sessão deve reunir diferentes perspectivas: proprietário, gerente do projeto, engenharia, planejamento, execução, contratos, suprimentos, qualidade, operação, manutenção e fornecedores quando adequado. A ausência de uma interface crítica pode produzir conclusões parciais.
Em projetos sensíveis, um facilitador independente reduz assimetria hierárquica e ajuda a separar fatos, interpretações e recomendações. O facilitador não substitui especialistas, mas conduz o método, controla a discussão e assegura registro consistente.
Perguntas que aprofundam a análise
Perguntas úteis investigam objetivos, expectativas, sinais antecipados, decisões, controles, causas e resultados. Em vez de perguntar apenas “o que deu errado?”, deve-se explorar quando a equipe percebeu o problema, quais informações estavam disponíveis, por que o controle não funcionou e como a resposta alterou o resultado.
Aspectos positivos também precisam ser analisados. Uma prática bem-sucedida deve ser compreendida para que possa ser repetida. Sem identificar condições, recursos e decisões que a sustentaram, o sucesso pode ser atribuído genericamente à competência da equipe e permanecer impossível de reproduzir.
Evitar o blame game
Segurança psicológica não elimina responsabilidade. Ela permite que profissionais exponham falhas, incertezas e decisões sem que a sessão se transforme imediatamente em julgamento pessoal. A análise deve concentrar-se em processos, informações, condições, interfaces e controles.
Quando houver indício de conduta imprópria, descumprimento deliberado ou matéria jurídica, o tema deve ser encaminhado ao processo competente. A sessão de lições não deve ocultar fatos, mas também não deve assumir funções disciplinares ou legais para as quais não foi estruturada.
Divergências e múltiplas perspectivas
Participantes podem interpretar o mesmo evento de maneira diferente. O registro deve distinguir fatos confirmados, hipóteses, opiniões e pontos ainda não resolvidos. Forçar consenso artificial pode eliminar informação relevante.
A curadoria posterior pode solicitar documentos, entrevistas adicionais ou análise técnica. Uma lição não deve ser publicada como verdade institucional quando sua base permanece controversa ou insuficiente.
Saídas da sessão
A reunião deve produzir registros estruturados, itens para análise, responsáveis e prazos. Não é necessário finalizar todas as lições durante o encontro. O objetivo é capturar contexto e hipóteses suficientes para a etapa de validação.
| Etapa da sessão | Resultado esperado |
| abertura | objetivo, regras, escopo e confidencialidade compreendidos |
| reconstrução | fatos, sequência, decisões e evidências organizados |
| análise | causas, fatores contribuintes e controles avaliados |
| comparação | sucessos, falhas e variações em relação ao esperado identificados |
| recomendação | possíveis ações e condições de aplicação definidas |
| fechamento | responsáveis, lacunas de evidência e prazos registrados |
Uma boa sessão investiga mecanismos, não procura culpados.
Facilitação independente, evidências e múltiplas perspectivas ajudam a separar fatos, causas, interpretações e responsabilidades.
Como documentar, analisar e validar uma lição aprendida
Uma lição precisa ser compreensível fora do projeto que a originou. Pessoas que não participaram da experiência devem conseguir avaliar sua relevância, limites e aplicação. Para isso, o registro deve utilizar estrutura consistente e linguagem técnica precisa.
Contexto e condição inicial
O documento deve identificar tipo de projeto, fase, disciplina, sistema, ambiente, regime contratual e características relevantes. Informações confidenciais podem ser generalizadas, mas a retirada do contexto não pode tornar a recomendação universal sem fundamento.
Também devem ser registradas premissas e condições existentes antes do evento. Uma decisão tomada em instalação operacional possui restrições diferentes de uma obra nova; uma contratação por EPC distribui responsabilidades de forma distinta de um modelo EPCM.
Evento, consequência e evidência
A descrição precisa separar o que ocorreu de suas consequências. Datas, documentos, medições, registros de teste e indicadores sustentam a análise. Expressões como “houve grande impacto” devem ser substituídas por efeitos identificáveis sobre prazo, custo, qualidade, segurança, desempenho, operação ou contrato.
A evidência pode incluir relatórios, RFI, não conformidade, mudança, ata, fotografia, resultado de ensaio ou histórico de configuração. O registro deve apontar referências sem duplicar indiscriminadamente documentos protegidos.
Causa e fatores contribuintes
A análise deve ultrapassar sintomas. O Diagrama de Ishikawa e outras técnicas de causa raiz podem apoiar a investigação, mas a ferramenta não substitui julgamento técnico.
Em projetos, causas frequentemente combinam requisitos incompletos, interfaces não atribuídas, dados tardios, decisões sem autoridade clara, critérios de aceite vagos, planejamento incompatível, comunicação fragmentada ou incentivos contratuais inadequados. A busca por uma causa única pode simplificar sistemas complexos.
Resposta adotada e resultado
A lição deve registrar como a equipe respondeu e se a resposta funcionou. Uma ação improvisada pode resolver o evento específico e ainda não ser adequada como padrão. Da mesma forma, uma recomendação não testada deve ser identificada como hipótese ou ação proposta.
Resultados positivos e efeitos colaterais precisam ser registrados. Acelerar uma entrega pode recuperar prazo e aumentar risco de retrabalho; adicionar inspeções pode reduzir falhas e criar gargalo. O conhecimento útil preserva os trade-offs.
Recomendação e aplicabilidade
A recomendação deve indicar ação, responsável típico, momento e condição. Em vez de “melhorar a comunicação com fornecedores”, uma formulação útil pode exigir matriz de submittals, marco de aprovação, responsabilidade pela interface e bloqueio da liberação para fabricação enquanto dados críticos estiverem pendentes.
O registro também deve indicar onde a recomendação não se aplica. A engenharia exige contexto; transformar experiências locais em regras universais pode substituir um erro por outro.
Classificação e nível de acesso
Metadados devem permitir pesquisa por disciplina, fase, sistema, cliente, setor, tipo de contrato, causa, impacto, fornecedor, tecnologia e criticidade. Também é necessário controlar confidencialidade, dados pessoais, propriedade intelectual, segurança e obrigações contratuais.
Uma versão institucional pode remover nomes e informações sensíveis, preservando o mecanismo técnico. Registros completos podem permanecer restritos a grupos autorizados.
Marco de qualidade antes da publicação
Antes de aprovar uma lição para reutilização, deve-se confirmar:
- O contexto está suficientemente descrito para avaliar a aplicabilidade.
- Fatos e interpretações estão claramente separados.
- Os impactos possuem evidências ou justificativas identificáveis.
- As causas foram analisadas além dos sintomas imediatos.
- A resposta adotada e seus resultados estão registrados.
- A recomendação é específica, executável e vinculada ao momento adequado.
- Limites, exceções e condições de aplicação estão explícitos.
- Referências e documentos de suporte podem ser localizados.
- Aspectos confidenciais, pessoais e contratuais foram tratados.
- Um responsável técnico revisou a consistência do conteúdo.
- O destino organizacional da recomendação foi definido.
- A lição possui data de revisão e critério de obsolescência.
Uma lição precisa ser tecnicamente defensável.
Contexto, evidência, causa, aplicabilidade e revisão são indispensáveis antes que uma recomendação seja reutilizada.
Como transformar lições em decisões, padrões e melhorias verificáveis
O principal fracasso de muitos programas não está na captura, mas na aplicação. Bancos extensos podem acumular relatos que raramente são consultados. Para gerar valor, o conhecimento deve entrar nos fluxos em que decisões são tomadas.
Vinculação a ações organizacionais
Cada lição priorizada deve possuir um destino: procedimento, template, checklist, contrato, critério de projeto, matriz de risco, treinamento, catálogo técnico, base de custos ou plano de inspeção. A publicação no repositório não substitui a mudança.
A solução de Gestão do Conhecimento Técnico e Lições Aprendidas pode estruturar curadoria, responsabilidades e reutilização. O fluxo deve registrar quem aprova, quem implementa, qual documento será alterado e como a eficácia será verificada.
Integração ao início dos projetos
Kickoff, planejamento de riscos, definição da estratégia de contratação e revisões de engenharia devem exigir consulta a lições relevantes. Essa exigência pode ser incorporada ao plano do projeto e aos gates.
O Gerenciamento de Riscos em Projetos de Engenharia se beneficia diretamente do histórico. Riscos ocorridos, sinais antecipados, respostas eficazes e falhas de controle formam uma base mais realista do que listas genéricas.
Integração a contratos e fornecedores
Lições sobre escopo, interfaces, submittals, aceites, garantias, produtividade e pleitos devem alimentar termos de referência e contratos futuros. Uma organização que reconhece padrões recorrentes e não altera seus documentos de contratação continuará reproduzindo as mesmas condições.
Avaliações de fornecedores também devem utilizar resultados contextualizados. Um atraso provocado por dados incompletos do proprietário não deve ser atribuído integralmente ao fornecedor; da mesma forma, desempenho positivo em um escopo simples não comprova capacidade para sistemas críticos.
Integração à engenharia e ao controle documental
Decisões técnicas relevantes podem gerar detalhes padrão, critérios de revisão, notas de projeto, bibliotecas, especificações ou checklists de compatibilização. A Governança Documental e Sistema de Gestão de Documentos deve assegurar revisão, aprovação e rastreabilidade dessas mudanças.
É importante evitar cópia automática. Uma solução bem-sucedida deve passar por avaliação técnica antes de tornar-se padrão. Normas, tecnologias e condições podem mudar, tornando a lição parcialmente obsoleta.
Recuperação contextual
Pesquisa por palavras-chave é necessária, mas pode ser insuficiente. O sistema deve relacionar lições a projetos, documentos, riscos, disciplinas, sistemas e decisões. Recomendações precisam aparecer quando o usuário trabalha em situação semelhante.
Taxonomia, metadados, filtros e resumos executivos facilitam a recuperação. Recursos de inteligência artificial podem apoiar busca e síntese, desde que preservem fonte, contexto, controle de acesso e revisão humana. Uma resposta gerada sem rastreabilidade não deve ser tratada como decisão técnica.
Indicadores de aprendizagem
Contar registros mede produção documental, não aprendizagem. Indicadores mais úteis avaliam consulta, aplicação, mudança de processo, recorrência e resultado. A organização pode acompanhar quantas lições foram incorporadas a padrões, quantos projetos demonstraram consulta prévia e quais problemas deixaram de repetir-se.
Também é necessário verificar efeitos não desejados. Uma nova regra pode reduzir determinado risco e aumentar prazo ou burocracia. O sistema deve permitir revisão e retirada de recomendações que perderam validade.
| Indicador | O que demonstra | Limitação |
| lições registradas | atividade de captura | não demonstra qualidade ou uso |
| lições validadas | funcionamento da curadoria | não demonstra aplicação |
| consultas por projeto | recuperação do conhecimento | não comprova influência na decisão |
| ações implementadas | conversão em mudança | exige verificar resultado |
| recorrência de causas | eficácia preventiva | depende de classificação consistente |
| redução de impacto | valor obtido | pode ser influenciada por outros fatores |
| revisões e obsolescências | manutenção da base | requer governança contínua |
O valor aparece quando a lição altera o trabalho futuro.
Recomendações devem alimentar riscos, contratos, padrões, projetos, treinamentos e controles com resultado mensurável.
Como implantar governança de lições aprendidas na engenharia
A implantação deve combinar processo, pessoas, tecnologia e cultura. Comprar uma plataforma sem definir responsabilidades produz repositório vazio ou desorganizado. Criar um procedimento sem integrar o trabalho aos projetos produz baixa adesão.
Papéis e responsabilidades
O gerente do projeto assegura captura e aplicação no âmbito do empreendimento. Especialistas validam conteúdo técnico. O PMO ou a função de governança padroniza o processo, consolida temas e acompanha ações. A gestão do conhecimento cuida de taxonomia, curadoria, acesso e ciclo de vida dos registros.
Lideranças precisam demonstrar uso real. Quando gestores solicitam apenas quantidade de registros, as equipes produzem documentos para cumprir requisito. Quando decisões, aprovações e revisões consultam a base, a aprendizagem torna-se parte da operação.
Processo mínimo viável
A organização pode começar com poucos campos obrigatórios, categorias controladas, facilitadores treinados e uma rotina de revisão. Complexidade excessiva reduz participação; simplicidade sem curadoria reduz valor.
O processo mínimo deve assegurar identificação, análise, validação, armazenamento, recuperação, aplicação e revisão. A maturidade pode crescer com integração a projetos, contratos, riscos, documentos e ativos.
Arquitetura da informação
O repositório deve possuir identificador, título, resumo, contexto, causa, impacto, recomendação, aplicabilidade, referências, classificação, responsável, status e revisão. Relações com projetos, disciplinas e documentos precisam ser estruturadas.
A solução ENGiOS — Plataforma de Gestão para Empresas de Engenharia pode apoiar integração entre conhecimento, documentos, projetos e governança. A ferramenta, entretanto, deve refletir o modelo operacional definido pela organização.
Modelo de maturidade
Em estágio inicial, equipes registram lições de forma isolada. Em estágio intermediário, existem processo, templates, curadoria e repositório. Em estágio avançado, lições alimentam decisões, riscos, contratos e padrões, com indicadores de aplicação e resultado.
Maturidade não é medida pelo tamanho da base. Uma biblioteca menor, confiável e utilizada pode gerar mais valor do que milhares de registros genéricos.
Escopo de uma consultoria
A contratação pode incluir diagnóstico, mapa de conhecimentos críticos, desenho do processo, taxonomia, templates, critérios de validação, governança, implantação de repositório, migração de registros, treinamento, indicadores e integração com PMO, GED e sistemas corporativos.
Propostas devem esclarecer quantidade de áreas, disciplinas, fontes existentes, nível de curadoria, volume de migração, integrações, perfis de acesso e suporte após a implantação. Não são comparáveis escopos que tratam apenas software e escopos que incluem transformação de processo e conteúdo.
Atuação da A3A Engenharia
A A3A Engenharia pode estruturar programas de lições aprendidas integrados a Gerenciamento de Projetos, Owner’s Engineering, EPCM, PMO e serviços continuados de engenharia consultiva.
A atuação pode abranger diagnóstico, desenho de governança, facilitação de sessões, análise técnica, curadoria, implantação de fluxos, organização de repositórios, integração com documentos e riscos e acompanhamento das ações de melhoria.
Uma organização aprende quando experiências deixam de permanecer em pessoas ou arquivos isolados e passam a orientar decisões futuras com contexto, evidência e responsabilidade.
Governança transforma memória em capacidade institucional.
Processo, curadoria, tecnologia e liderança precisam funcionar juntos para que o conhecimento seja recuperado e aplicado.
Conheça a solução de Gestão do Conhecimento Técnico e Lições Aprendidas
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 30401:2018 — Knowledge management systems — Requirements. Geneva, 2018.
[2] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/DIS 30401 — Knowledge management systems — Requirements, edition 2. Geneva, 2026.
[3] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 21502:2020 — Project, programme and portfolio management — Guidance on project management. Geneva, 2020.
[4] ROWE, Sandra F.; SIKES, Sharon. Lessons learned: taking it to the next level. Newtown Square: Project Management Institute, 2006.
[5] WILLIAMS, Terry. Post Project Reviews to Gain Effective Lessons Learned. Newtown Square: Project Management Institute, 2007.
[6] NATIONAL AERONAUTICS AND SPACE ADMINISTRATION. Lessons Learned Information System. Washington, DC, 2021.
Perguntas frequentes
São conhecimentos derivados de experiências reais que explicam contexto, causas, resultados e recomendações aplicáveis a situações futuras.
Não. A captura deve ocorrer durante o planejamento, em fases e marcos, após eventos críticos, em revisões periódicas e no encerramento.
O registro preserva informação. A aprendizagem ocorre quando o conhecimento é validado, aplicado a uma decisão ou processo e produz resultado verificável.
A facilitação deve separar fatos, interpretações e responsabilidades, concentrar a análise em causas e controles e encaminhar questões disciplinares ou jurídicas aos processos adequados.
Contexto, evento, impacto, evidências, causas, resposta, resultado, recomendação, aplicabilidade, referências, responsável e revisão.
Além de contar registros, deve-se avaliar consultas, ações implementadas, alterações em padrões, recorrência de causas e resultados obtidos.
Materiais técnicos complementares
Whitepapers
- Owner’s Engineering: framework executivo para contratação, governança e aceite
- ENGiOS — Plataforma de Gestão Técnica para Empresas de Engenharia
Artigos técnicos
- Gestão de riscos em projetos de engenharia
- Project Controls: planejamento e controle de projetos de engenharia
- Diagrama de Ishikawa
- Diagrama de Pareto na gestão de projetos
- PMO: o que é, tipos e funções
- PDCA: melhoria contínua
