Descobertas do PPM Benchmarking Report da AXELOS de 2019

Recentemente a AXELOS publicou o PPM Benchmarking Report de 2019 (PPM: Project Portfolio Management ou Gerenciamento de Portfolio de Projetos).  

O relatório foi desenvolvido para oferecer uma visão do mercado sobre o status do gerenciamento de projetos e programas, destacando as tendências crescentes e os principais problemas encontrados. Algumas descobertas importantes desse trabalho são apresentadas abaixo:

Fazendo mais com menos

Devido a fatores econômicos, mercados voláteis e mudanças tecnológicas, a pressão está aumentando nas organizações e nas equipes de projeto. Isso significa que os gerentes de projeto e programa são confrontados com a perspectiva de atender às expectativas crescentes das partes interessadas de oferecer maior vantagem competitiva com orçamentos reduzidos em prazos mais rígidos. Devido a esse foco, oito em cada dez gerentes de projetos agora dizem que o PPM está se tornando um aspecto mais fundamental do sucesso geral dos negócios.

Efeitos da IA ​​e do GDPR

A IA (Inteligência Artificial) é vista como amiga ou inimiga? A pesquisa mostrou que mais gerentes de projeto reconheceram a automação e a IA como oportunidades, e não como ameaças. Do ponto de vista de um gerente de projeto, faz todo o sentido, pois, quando utilizados corretamente, tais elementos podem fornecer ferramentas que economizam tempo e que aumentam a eficiência do projeto, em vez de ameaçar suas funções. No entanto, o GDPR (General Data Protection Regulation ou Regulamento Geral sobre a Proteção de Dados) tem o potencial de retardar o desenvolvimento de projetos e programas, à medida que os recursos são canalizados para isso, garantindo que o projeto ou programa cumpra os padrões regulatórios.

Comunicação pobre

A falta de comunicação continua sendo o maior desafio que dificulta projetos e programas. Mesmo com a introdução de novas tecnologias de comunicação, muitas equipes de projeto ainda falham. Quando perguntados, alguns gerentes de projeto ressaltaram a importância do desenvolvimento de “habilidades básicas ou flexíveis”, como a comunicação.

O que podemos aprender com as equipes bem-sucedidas de gerenciamento de projetos?

Fornecendo o básico

Precisamos garantir que a equipe possua processos monitorados e avaliados continuamente. É importante que as revisões de projeto sejam conduzidas adequadamente e que assegurem que as lições aprendidas sejam identificadas e aplicadas nos projetos futuros. A pequisa notou que o uso das revisões finais do projeto ainda é baixo. Para que as revisões finais do projeto sejam realizadas em níveis mais altos, é necessário haver um comprometimento da gerência sênior para que elas ocorram e um entendimento de que elas são parte integrante do projeto. É interessante notar que as organizações bem-sucedidas são mais propensas a realizar revisões finais do projeto.

O papel da gerência sênior

É útil que a equipe do projeto/PPM tenha representação em um nível de gerência sênior, para que os outros gerentes seniores vejam o valor que a equipe do PPM traz e aprecie os desafios que enfrentam.

Garantindo agilidade

É provável que as equipes de sucesso trabalhem de maneira ágil e isso é apoiado pela pesquisa que afirma que "três quartos dos entrevistados afirmam estar trabalhando de maneira ágil e acreditam que isso está tendo um impacto positivo no sucesso dos negócios". No entanto, a principal barreira que impede que mais equipes adotem o Agile é a falta de suporte e entendimento da organização em geral.

Bem, é isso aí! Até a proxima!

*********************************************************

Sobre a AXELOS:

A AXELOS é uma joint venture, criada em 2013 no Reino Unido, para gerenciar, desenvolver e aumentar o portfólio de melhores práticas globais. A AXELOS possui um portfólio de qualificações de melhores práticas reconhecidas globalmente.

A AXELOS é responsável pelo desenvolvimento, aprimoramento e promoção de várias estruturas e metodologias de melhores práticas usadas globalmente por profissionais que trabalham principalmente em gerenciamento de serviços de TI, gerenciamento de projetos, programas e programas e resiliência cibernética.

Esses métodos, incluindo ITIL®, PRINCE2®, MSP® e nossa coleção de produtos de melhores práticas de resiliência cibernética, RESILIA®, são adotados por setores privados, públicos e voluntários em mais de 150 países para melhorar as habilidades, o conhecimento e a competência dos funcionários, a fim de fazer com que indivíduos e organizações trabalhem de forma mais eficaz.

Para encontrar o PPM Benchmarking Report da AXELOS de 2019 acesse o link > https://www.axelos.com/ppmbenchmark2019

UM POUCO DE HUMOR ...

Práticas Ágeis em Projetos que NÃO são de Software

Os métodos que vêm debaixo do chamado guarda-chuva “Agile” incluem abordagens como, por exemplo, o Scrum, o RUP (Rational Unified Process) e o XP (Extreme Programming), todas feitas para projetos de software. 

Apesar disso, muitos seguidores  do “Agile” costumam apresentar essa filosofia de gestão de projetos como uma verdadeira bala de prata para qualquer tipo de projeto, ou seja, o jeito mais moderno de gerenciar um projeto de software ou de qualquer outro tipo, alinhada a filosofia “lean manufacturing”, que faz o projeto acontecer de forma rápida, que corta desperdícios com coisas desnecessárias, que reduz custos e outros benefícios.  

Essa ideia de entender que o “Agile” (ágil em português) seria o mesmo que rápido, esquecendo as premissas que formam a base do conceito do “Agile”, costuma ser explorada por algumas empresas, na ânsia de convencer seus colaboradores que eles (e elas) precisam trabalhar mais depressa, a ao mesmo tempo sem perder a precisão e o foco, para alcançar o sucesso nos projetos que desenvolvem em um tempo menor do que o de costume. A bala de prata, a tal solução para todos os problemas, para evitar o fracasso dos projetos, está na abordagem “Agile”. Todos querem o tiro certo, sem desperdício, e se você não sabe trabalhar com algum método ágil, você não serve mais para a empresa. Trate de se modernizar, ou será chamado de retrógrado e ultrapassado! E isso será usado até que uma nova bala de prata seja descoberta.

Pesquisas apontam que as causas principais de fracasso em projetos se referem a mudança de escopo, falta de comprometimento das equipes, incorreções no business case, falta de recursos, prazos inexequíveis e riscos não gerenciados. Há ainda outras causas como incapacidade gerencial, falta de comprometimento da alta direção, falta de método para gerenciar o projeto e habilidade técnica insuficiente. Mas, a primeira causa de fracasso de um projeto (aproximadamente 70% das causas de fracassos em projetos) está associada as constantes mudanças de escopo. O projeto é iniciado e apesar de não se saber bem o que precisa ser feito, o projeto segue adiante e em algum momento se descobre que alguma coisa está faltando (ou está incorreta, ou imprecisa, ou a mais, ou a menos), sendo necessário acrescentar alguns itens no escopo não considerados no plano original, ou retirar itens inicialmente inclusos e que nesse ponto do projeto se mostram desnecessários. Então, sim, um planejamento mal feito ou apressado, pode ter graves consequências para o projeto. Da mesma forma pode acontecer do cliente - que está pagando pelo resultado que o projeto se propõe a entregar - não saber exatamente do que precisa. Durante a reunião de aprovação do projeto pode surgir a seguinte frase dita pelo cliente: - É o seguinte pessoal, eu quero um resultado bem legal, e assim vocês vão desenvolvendo e eu vejo se vai ficar bom e se eu gostar, seguimos em frente”.  Nossa, o “máximo”! 

Quando se trata de projetos de software não saber exatamente o que será feito no início do projeto não é algo assim tão incomum. Por exemplo, alguém pode ter uma ideia para um aplicativo que pode gerar milhares de dólares e isso ser apresentado de forma geral do ponto de vista técnico e, ao mesmo tempo, algo bastante atrativo ponto de vista financeiro. Em outras palavras, no início não se sabe exatamente como o aplicativo vai rodar, como serão as opções no menu do usuário para que tudo funcione perfeitamente, além de outros detalhes operacionais. Essas coisas serão feitas durante o projeto. Por conta disso, será necessário ter a mente aberta e ser flexível com o escopo do projeto. 

O pessoal que elaborou o Manifesto Ágil, de 2001, estabeleceu princípios que orientam como o trabalho deve fluir nos projetos de software, e consideram quatro aspectos:

• Comunicação: indivíduos e interação entre eles mais que processos e ferramentas;
• Praticidade: Software em funcionamento mais que documentação abrangente;
• Alinhamento de expectativas e colaboração: colaboração com o cliente e membros do projeto mais que negociação de contratos;
• Adaptabilidade e flexibilidade: responder a mudanças mais que seguir um plano.

A boa comunicação interna e externa (entre os membros da equipe e com o cliente) é ressaltada. Através dessa boa comunicação e constante alinhamento de expectativas o software é produzido de forma prática (mais software funcionando e menos documentação). A equipe do projeto deve estar aberta as mudanças de escopo, ao invés de ficar protegendo o escopo original inicialmente considerado. Essa flexibilidade – diretamente ligada à forma como o projeto trata as mudanças de escopo - é vital para que o resultado seja realmente alinhado aos desejos e anseios do cliente. No Scrum, por exemplo, o método ágil mais utilizado, o projeto é desenvolvido em rodadas de curta duração chamados de sprints. Cada sprint tem, tipicamente, entre 2 a 4 semanas. Um escopo inteiro do projeto - que produz o software completo - é dividido em partes. Digamos, apenas para ilustrar, que para desenvolver o software completo do nosso exemplo, sejam necessários 10 sprints. Durante cada sprint são realizadas reuniões diárias de andamento do projeto e partes do software são desenvolvidas para serem entregues ao cliente. A estratégia aqui é a mesma inventada pelos Romanos: Dividir e vencer. O fato de trabalhar criando partes menores em um curto espaço de tempo (de 2 a 4 semanas) é um facilitador importante para discutir/negociar/fazer modificações no software em função de eventuais solicitações de mudança pelo cliente. Apenas para comparar, seria muito mais difícil responder as mudanças se o projeto estivesse sendo gerenciado considerando fases longas de um cronograma.

Os projetos de software têm suas características próprias e, evidentemente, têm várias diferenças em relação a outros tipos de projetos. Apesar dessa questão óbvia, vale a pena fazer uma comparação com os projetos de construção civil, que costumam usar o método cascata (gerenciamento de projetos tradicional que adota as melhores práticas do guia PMBOK do PMI). Aqui vamos tratar de apenas um aspecto bastante simples, mas que mostra não ser tão fácil ser flexível com o escopo do projeto. Digamos que, por exemplo, o cliente que está comprando um prédio de dez andares decide, depois de concluídas as fundações da edificação e parte das paredes dos primeiros andares, que esse prédio deve ter quinze andares. É óbvio que acrescentar cinco andares à essa edificação causaria problemas ao projeto, uma vez que tudo no prédio foi calculado para um total de dez andares. Na prática, para aceitar essa mudança seria necessário derrubar o que foi feito e reiniciar a construção. Ser flexível com a mudança de escopo aqui não é uma opção. Uma mudança de escopo que geraria impactos negativos (atraso no cronograma, estouro no orçamento, etc). Portanto, essa solicitação de mudança não seria aprovada!  Como o exemplo do prédio de dez andares do ramo da construção civil, há muitos tipos de projetos que necessitam ser muito bem definidos desde o seu início. Esses projetos precisam ser muito bem planejados e seus escopos muito bem definidos, e se isso não é contemplado o risco do projeto fracassar é bem real.

Sim, mas não há nada que possa ser aproveitado dos métodos ágeis em outros tipos de projeto que não sejam de software? Me parece que a resposta é sim. Então, vejamos algumas ideias que, sempre que possível, podemos usar:

Criar uma lista de itens prioritários (similar ao “backlog”do Scrum) – isso ajuda a decidir o que será feito. 

Escrever descrições resumidas sobre o que será feito (similar as “user stories”do Scrum) – isso facilita o planejamento e a discussão sobre o que será feito.

Mostrar em um quadro ou mesmo na parede, para a equipe e as partes interessadas, o progresso do projeto (similar ao Kanban) – isso permite ter uma visão geral do trabalho que está sendo feito. 

Definir períodos curtos de tempo para executar partes do trabalho do projeto (similar aos sprints do Scrum) – isso facilita o planejamento/controle do trabalho da equipe do projeto para executar o que será feito.

Adotar reuniões rápidas e diárias de acompanhamento do progresso do projeto com o pessoal da equipe de pé, e com duração máxima de 10 minutos (similar as standup meetings do Scrum) – isso facilita a comunicação através de reuniões objetivas e focalizadas no trabalho que está sendo feito.

Organizar reuniões de retrospectiva ao final de cada período de trabalho (similar as retrospective meetings do Scrum) – isso possibilita discutir o que funcionou e deu certo e o que não deu certo no projeto e precisa ser melhorado ou mesmo descartado do ambiente do projeto.

Bem, é isso aí! Até a próxima!