O que são as lessons learned, como capturar as informações e registrá-las na organização, e como acessá-las? É sobre o que fala Armando Terribili Filho, da Unisys.
O termo “lições aprendidas” na área de gerenciamento de projetos é muito utilizado, tanto que deixou de ser um simples termo para se tornar um jargão amplamente disseminado na área. Antes de responder à pergunta proposta neste artigo (utilidade ou burocracia?), seria conveniente considerarmos três aspectos: (1) definir o que são lições aprendidas em projetos (ou “lessons learned”) e para que servem; (2) como capturar as informações e registrá-las na organização; e (3) como organizá-las para permitir o acesso a elas. Como nota de rodapé quanto ao “acesso das informações”, deve-se debater a questão do nível de autoridade para recuperá-las e a questão da confidencialidade.
Conceitualmente, uma “lesson learned” é qualquer aprendizagem ocorrida durante o desenvolvimento de um projeto, seja uma ocorrência positiva ou negativa, que pode se repetir em projetos futuros. Uma “lesson learned” pode ser um erro de planejamento identificado na execução do projeto, a utilização de uma boa ferramenta para cálculo de estimativas, o desempenho de um novo fornecedor, uma estratégia bem sucedida para abordar determinado tipo de risco no projeto, etc. A reincidência desses fatos impactarão os futuros projetos (sobretudo, os similares), por isso, as “lessons learned” permitem que os gerentes de projetos tomem medidas preventivas e/ou corretivas sejam em nível de planejamento de seus projetos, como de execução. Um exemplo seria de um projeto para realização de uma feira internacional em um país europeu, que quando do planejamento, não houve a devida atenção para a questão de compatibilidade de tomadas para ligar equipamentos elétricos na rede de energia. Quando na montagem do stand para realização da feira, o problema foi detectado, envolvendo contratação em nível emergencial de empresa local especializada para fazer as adaptações, o que trouxe ao projeto, custos não-previstos, além de elevação dos riscos na execução do projeto. Nada melhor que registrar a ocorrência para evitar que casos similares tenham as ações previamente executadas; ou mesmo, em caso de repetição na ocorrência, as ações corretivas que foram aplicadas no passado também sejam conhecidas, facilitando a solução do problema.
Manter os registros exclusivamente “na cabeça” das pessoas é algo efêmero, pois as pessoas se envolvem com outros projetos, se esquecem dos fatos, além de que, os profissionais mudam de organizações, se aposentam ou se afastam por licença médica. Neste cenário surge o segundo aspecto relevante no processo: a captura e registro das “lessons learned”. Evidentemente que as ocorrências no projeto ocorrem o tempo todo, entretanto, nem sempre se tem tempo para registrá-las, uma vez que estamos totalmente imersos na execução do projeto. É justamente por isso, que em muitas organizações nas reuniões de encerramento de fase de projeto ou reunião de encerramento de projeto, há na pauta o tema “lessons learned” formalizado. O registro das “lessons learned” é um problema de processo e sistema, ou seja, temos que ser suficientemente sintéticos para resumir o ocorrido, porém, sem negligenciar o detalhamento do problema, do impacto causado e da solução encontrada. Quanto ao sistema, nem sempre a organização dispõe de uma base de dados criada para este fim, por isso, registros avulsos em papel ou em arquivos não-estruturados tendem a se perder rapidamente. Neste aspecto, a organização sistêmica da informação e a criação de palavras-chave para possibilitar a recuperação da informação são vitais para o efetivo uso da importante base histórica de conhecimento.
Neste contexto deve-se avaliar também qual o nível de autoridade que o profissional deve ter para acessar a base de dados, bem como, qual o tipo de informação que lhe é disponível. Quando se fala em “democratização da informação” não se pode inferir que todas as informações são públicas, mas sim, que o acesso é permitido para todos com nível de autoridade compatível com a informação. Além disto, há um cuidado adicional que precisa ser constantemente relembrado: a confidencialidade da informação. Os registros devem ser analisados para que eventuais identificações críticas que não podem ser divulgadas, permaneçam preservadas, como: nome de clientes, nome de profissionais, quantitativos sigilosos, etc. Assim, esses dados precisam ser omitidos na base de forma categórica, sem deixar indicativos que permitam identificá-los.
Assim, é indiscutível que a existência de uma base de dados com as “lessons learned” de projetos é de suma importância para os futuros projetos da organização, potencializando acertos e eliminando riscos. A criação, a manutenção e o compartilhamento desta base devem ser de responsabilidade do PMO (Project Managament Office) ou Escritório de Projetos, exceto no caso de projetos grandes que podem criar seu próprio repositório de dados.
Além dos requisitos processuais (procedimentos também definidos pelo PMO), os aspectos sistêmicos precisam ser considerados, para que as informações sejam facilmente registradas e possam ser rapidamente recuperadas, com o devido respeito da confidencialidade das informações. Assim, retornando ao questionamento apresentado no título se “lessons learned” são úteis ou burocracia, a resposta dependerá da abordagem adotada pela organização. Se a organização não tiver procedimentos simples e adequados, bem como sistemas amigáveis de fácil utilização, poderá criar um “elefante branco”, com perda de tempo de seus profissionais na alimentação da base de dados que, por sua vez, será pouco utilizada. Entretanto, a sistematização inteligente, objetiva e profissional das “lessons learned” traz uma certeza: evitar que a organização “reinvente a roda” constantemente, pois isto traz acréscimo de custos, de prazos, dos riscos, podendo comprometer a qualidade das entregas do projeto e a motivação da equipe.
(*) Armando Terribili Filho (PMP) é diretor de projetos na Unisys Brasil, doutor em Educação pela UNESP, mestre em Administração de Empresas e docente na FAAP e no SENAC São Paulo. É autor do livro “Indicadores de gerenciamento de projetos: monitoração contínua” (M. Books, 2010). Neste mês, lançará “Gerenciamento de Projetos em 7 passos: uma abordagem prática”, pela mesma editora.
