Estamos dando sequência neste terceiro e último artigo à série em que apresentamos um conjunto de boas práticas de gestão de projetos.
Neste artigo, vamos tratar das últimas 5 boas práticas (BP#11 a BP#15), se você não leu os artigos anteriores, aqui vão os links:
Boas Práticas de Gestão de Projetos – Parte 1 https://criteriologico.com.br/boas-praticas-de-gestao-de-projetos-parte-1/gestao-de-projetos/
Boas Práticas de Gestão de Projetos – Parte 2 https://criteriologico.com.br/boas-praticas-de-gestao-de-projetos-parte-2/inovacao/
Como já mencionado nos artigos anteriores, tais boas práticas foram reunidas ao longo de 20 anos de atividade profissional minha (e de colegas) com projetos, em diferentes organizações.
Vamos então às últimas 5 boas práticas:
BP#11: A partir das entregas do projeto, crie uma WBS para obter uma visão comum do escopo do projeto.
Certamente aqui os defensores do ágil vão “torcer o nariz” pelo fato desta ferramenta ser mais ortodoxa mas, por favor, me deem tempo para explicar.
Como já explorado na BP#10, entregas são um importante instrumento para materializar os resultados do projeto, inclusive auxiliando na árdua tarefa de “alimentar os tigres” corporativos (alta gestão).
Assim, uma interessante alternativa para melhorar a comunicação com estes e demais stakeholders chave, inclusive seu time, é criar um mapa gráfico do escopo do projeto, mesmo que ele venha a mudar, fruto da evolução na jornada de descoberta e entrega de valor.
Este mapa do escopo, já entendido como evolutivo por natureza, pode ser representado em uma WBS – Work Breakdown Strucutre ou Estrutura Analítica de Projeto (EAP).
Uma WBS ajuda muito em mostrar os elementos do seu desafio, da entrega de valor do projeto, além de ser uma forma evidente (gestão a vista) de mostrar o que já foi feito e o que há por fazer.
Assim, entendo como importante recorrer a este instrumento para “colocar todos na mesma página”, como um GPS do caminhar da execução, pense nisso.
BP#12: Crie um cronograma enxuto do projeto.
Novamente corro o risco de ser mal interpretado aqui, não me refiro nesta boa prática aos cronogramas tradicionais, com muitas tarefas e relações lógicas.
Na minha visão tais cronogramas mais funcionam como uma “camisa de força” para o projeto, prejudicando a adaptabilidade frente aos desafios externos, ao invés de direcionar caminhos…
Um cronograma enxuto, com apenas as macro etapas e deadlines (datas limite) serve para, assim como a WBS, mostrar o caminho que o time seguirá na sua jornada de entrega de valor.
Este caminho, demonstrado desta forma, ajuda inclusive a trazer uma certa segurança ao time, evitando que se sinta perdido, risco observável em cenários de equipes praticando o ágil.
Neste cronograma as entregas podem e devem ser identificadas, associadas aos marcos do projeto (milestones), sem detalhamento de tarefas, visto que tais pormenores serão definidos à medida que o projeto avança e por decisão da equipe.
Um cronograma assim é um belo instrumento para apaziguar os ânimos dos “tigres” corporativos, visto que demonstra o projeto em um racional de entrega, servindo assim como uma ferramenta de stakeholder management.
BP#13: Cuidado ao determinar a relação custo-benefício do projeto.
Este é um tema sério que aflora ao ver apresentações (pitchs) de projetos mal preparadas, orçamentos mal feitos e projeções de retornos ou mal calculadas, ou com otimismo demasiado.
Um pitch é um momento vital para o projeto (e para quem o apresenta), nele a alta gestão fará sua apreciação e teremos o go/no go.
Assim minha recomendação é que qualquer orçamento de projeto seja feito com o apoio de um especialista, que pode ser da área financeira ou do próprio PMO (Project Management Office) da organização.
O mesmo vale para o cálculo dos benefícios…
Uma certeza podemos ter, na hora de apresentar os números (Orçamento e ROI do Projeto) alguém vai perguntar sobre como foram determinados e é necessário ter segurança neste momento, é um teste importante.
Esteja preparado para este momento, busque conhecimento, não ache que sabe o suficiente para fazer estas demonstrações, alinhe antes todos os racionais de cálculo também com o patrocinador (sponsor) do projeto…
Segurança em um pitch é vital, números são a linguagem dos gestores, tenha fluência neste idioma.
BP#14: Seja ágil! Acompanhe a execução do projeto através de um quadro de SCRUM.
Um quadro de SCRUM do projeto, o qual apresenta o conjunto de atividades, nos seus respectivos status (A FAZER/FAZENDO/FEITO) tem uma simplicidade e poder sobre a execução do projeto que não consigo encontrar em outro instrumento, quando o assunto é manter o time focado nas atividades que agregam valor.
Mas é preciso ter um cuidado, é importante que este quadro seja atualizado de forma contínua, assim alguém do time precisa assumir esta responsabilidade, em alguns cenários este indivíduo é o chamado scrum master.
Esta ferramenta é muito eficaz para fazer o acompanhamento da execução, e inclusive não precisa de nenhuma tecnologia rebuscada, basta um simples quadro branco.
“Simplicidade é o mais alto grau da sofisticação”, já dizia Leonardo da Vinci.
Mantenha este quadro em um local visível para todos do time, esta ferramenta inclusive o ajudará a manter o senso de urgência no grupo, condição tão importante, já comentada em nosso artigo anterior, como instrumento de engajamento da equipe.
E agora a última (e não menos importante) boa prática…
BP#15: Arquive toda documentação de forma organizada ao longo do projeto, ao final conduza uma reunião de post mortem.
Em 20 anos de consultoria sou capaz de contar nos dedos de uma das mãos situações em que me deparei com departamentos que faziam uma gestão minimamente adequada da documentação de seus projetos, para fins de arquivamento.
E para isso não estou falando necessariamente de gestão do conhecimento em último grau ou softwares específicos, apenas de uma simples boa vontade em organizar as informações, imaginando que um dia, no futuro, elas podem ser consultadas para algum novo projeto (servindo de lições aprendidas ou lessons learned).
Pois é, frustrante é começar um projeto e saber logo depois que algo muito semelhante foi conduzido anos atrás, e a informação se perdeu, particularmente nos notebooks de seus idealizadores, que agora estão em outras organizações…
Daí a constatação de “reinventar a roda” tem seu espaço, desperdiçando energia com indivíduos comentendo os mesmos erros, mesmo por ignorância…
Melhor do que aprender com os próprios erros, é aprender com os dos outros.
Minha dica aqui é, se não há uma boa gestão de documentos dos projetos na sua área ou organização, comece a fazer esta gestão a partir do seu projeto, reúna as principais reflexões, entregas, resultados de testes, documentações de provas de conceito, além dos documentos mais tradicionais, como cronogramas e especificações de produto.
Organize em pastas, quer físicas ou na rede, digo na rede pois quantas não foram as vezes que tais documentos estavam em um computador em particular e, como a sorte nem sempre sorri para nós, uma falha na máquina fez todo o conteúdo do seu HD ser perdido, e aí se foram as informações.
Outra alternativa é o uso de pastas na nuvem, a qual eu indico e tenho feito intenso uso.
Uma dica final é conduzir uma reunião de post mortem com os principais stakeholders e o time ao final do projeto, a fim de coletar como foi a experiência do projeto para eles, quais os momentos mais difíceis, quais os mais fáceis, que comportamentos precisamos mudar e que lições tiramos para futuros projetos.
Como sei que é difícil reunir todos, o uso de teleconferência é uma alternativa, você pode organizar um webinar para fazer isso, é até um meio elegante de “fechar” o projeto.
Muito bem, aqui concluímos nossa jornada pelas 15 boas práticas, espero que você tenha gostado, procurei organizá-las e detalhar cada uma delas de forma que você possa aplicá-las nos seus projetos.
Se você gostou destes artigos, compartilhe-os na sua organização! A intenção é esta, trazer conteúdo de qualidade aos amigos que vivem a dura (e emocionante) rotina de gestão de projetos.
Sucesso pra você! Abs…