5 qualidades indispensáveis ​​dos principais gerentes de projeto

Ouça a versão em áudio deste artigo

Ser um PM top faz você se destacar e se você for reconhecido como sendo um PM top, você estará em alta demanda. As partes interessadas confiarão mais em você, desejarão trabalhar com você e ouvirão mais seus conselhos. Seja o que for que você esteja ajudando a construir, os melhores PMs estão sempre em demanda em organizações em todo o mundo. Esta é uma lista de algumas qualidades-chave dos principais gerentes de projeto. Espero que eles ajudem você a se tornar um ou verifique se você já tem esses hábitos à sua disposição.

1. Construindo confiança em sua equipe

A confiança é um aspecto importante de cada equipe. É frequentemente falado e escrito, mas raramente visto em ação quando se trata de executar um projeto. A importância da confiança no processo de gerenciamento de projetos foi reconhecida por diversas organizações de gerenciamento de projetos.

A International Project Management Association acaba de incluir seções sobre confiança em sua certificação ICB4, que é o padrão global para competências individuais em gerenciamento de projetos, programas e portfólio.

Da mesma forma, os Três Pilares do Empirismo do Scrum há muito se baseiam na ideia de que a confiança é um dos três fatores mais importantes para sustentar o controle empírico do projeto. A mesma tendência de construção de confiança está presente no LEAN e em outras metodologias tradicionais de gerenciamento de projetos. Se este tem sido um tema tão urgente por tanto tempo, quais são os principais bloqueadores que impedem os PMs de estabelecer uma confiança real dentro de suas equipes?

Uma das respostas mais recorrentes a essa pergunta é a “cultura da culpa”. A chave para alcançar a cultura de confiança é migrar para longe dessa cultura e, em vez disso, transformar cada erro em uma oportunidade de aprendizado.

Para tornar isso uma realidade, os PMs devem facilitar o ambiente certo de transparência e conforto dentro de suas equipes, já que a maioria das pessoas tem um desempenho muito melhor no ambiente em que os membros da equipe são capazes de se expressar e cometer erros.

Um PM de alto nível ensina à sua equipe esses princípios pelo exemplo, vivendo ao lado deles, incentivando a compartilhar seus erros e transformando-os em exemplos de aprendizado. Os principais PMs percebem que mostrar humildade e vulnerabilidade é um sinal de força. Especialmente quando se trata de admitir seus próprios erros, muitas vezes é verdade que as pessoas tendem a se tornar defensivas ou transferir a culpa. Explicar que você cometeu um erro e por que pode fazer você se sentir vulnerável, mas se você admitir e analisar abertamente esses erros, esse hábito ajudará outras pessoas a evitá-lo no futuro e ajudará todos a construir confiança e se abrir sobre seus deslizes . Por exemplo, se você prometer demais a uma parte interessada importante terminar um marco antes do que é possível, devido à falta de profundidade técnica que você tinha nesse assunto, admita seu erro para a equipe e deixe-os saber que você errou as coisas em vez de culpar por não entregar a tecnologia tão rápido quanto você queria. Isso pode inspirar outras pessoas a se abrirem e construírem conexões mais fortes com você e seus colegas de equipe.

Entenda os membros da sua equipe: suas capacidades, medos, frustrações, o que eles gostam ou não gostam e como eles interagem com outras pessoas. Quando os membros da equipe sentem que são valorizados, eles entregam valor com mais facilidade. Encontre maneiras de motivar sua equipe com a tarefa em mãos, em vez de empurrá-los com força para seus objetivos. Para fazer isso, descreva claramente como é o sucesso do projeto e das funções e responsabilidades da equipe do projeto, mas deixe que eles sejam especialistas em seus campos. Espere que os membros de sua equipe lhe digam o que precisa ser feito. Ouça-os, descentralize a tomada de decisões para capacitar sua equipe, mas esteja preparado para tomar decisões difíceis quando necessário.

Afinal, sua equipe está lá para você se envolver. Muitos PMs cometem erros de mergulhar direto nas tarefas de escrita e assumir muito dessa responsabilidade sozinhos. Isso às vezes acontece devido à falta de confiança e compreensão dentro dessas equipes. Quando você tem a confiança de sua equipe, certifique-se de que eles se envolvam no escopo do trabalho, escrevendo histórias de usuários e, em geral, dando conselhos sobre os assuntos que consideram importantes.

Os principais PMs percebem que sua equipe é seu melhor ativo e aproveitarão cada oportunidade para construir relacionamentos fortes com eles. Seja negociador e facilitador, mas antes de tudo, seja um com a equipe. Eles precisam sentir que você está trabalhando com eles e não para alguém acima. Este é um precursor de algumas das dicas mais técnicas deste artigo, pois, sem essa confiança, seu projeto provavelmente terá uma série de problemas.

Key Takeaway: “Não há problema em mostrar que todos cometem erros. Compartilhe seus erros quando os cometer, mostre à sua equipe que você está do lado deles e faça da confiança dentro de sua equipe uma prioridade.”

2. Envolver seus stakeholders para obter o que eles realmente precisam

Como PM, você provavelmente está bem ciente do fato de que muitos projetos de software acabam entregando algo diferente do que as partes interessadas queriam ou precisavam. Este problema é devido a muitos fatores diferentes e gerou todo um conjunto de novas metodologias tentando resolver este problema.

No entanto, mesmo na era do desenvolvimento ágil, às vezes ainda caímos na armadilha de construir a coisa errada. A análise das partes interessadas é essencial, mas geralmente começa com a pergunta errada. Sem fazer a pergunta “Por que estamos fazendo isso?”, muitos projetos são iniciados e definidos incorretamente, caindo na armadilha de construir uma solução que nunca atendeu à real necessidade do negócio.

Em conjunto com “por que”, os principais PMs devem perguntar um acompanhamento de “para quem?” Quais partes interessadas estamos apoiando, a fim de entregar a solução, para cobrir seus “porquês?”

Aqui é onde um PM top reconhece uma distinção importante. A solução pode ser definida como uma saída ou entrega, mas um PM de primeira linha entende que qualquer solução em si não cobrirá necessariamente a necessidade original do negócio. Por exemplo, se as partes interessadas acham que sua necessidade de negócios é implementar um sistema ERP, o PM deve ajudá-los a descobrir a real necessidade de negócios por trás do uso de uma solução como o ERP. O ERP em si é uma solução, não uma necessidade de negócios.

Reconhecer a verdadeira necessidade do negócio requer uma compreensão profunda do contexto e das partes interessadas, suas atitudes, nível de poder ou influência, nível de interesse, seu impacto no projeto, o impacto do projeto sobre eles, suas preocupações e, claro, o que eles aceitarão como o sucesso de um projeto.

Assim, a fim de tornar os projetos mais bem-sucedidos em atingir seu propósito – criar soluções que impactam os objetivos de negócios – as responsabilidades do gerente de projeto se expandem além da própria criação da solução, para onde as soluções são implementadas, medindo claramente se o valor realmente produzido está alinhado com os objetivos esperados na definição do objetivo.

Os PMs devem sempre ter em mente que os benefícios reais de entregar o projeto ao longo de todo o processo devem estar alinhados às necessidades, metas e objetivos reais do negócio.

Muitas vezes, os objetivos de negócios são esquecidos no meio do desenvolvimento e das mudanças de requisitos. Muitas vezes, os projetos acabam entregando produtos funcionais, que resolvem algumas, mas não todas as necessidades reais de negócios que inicialmente levaram ao desenvolvimento do produto. Isso pode ser evitado se as partes interessadas forem gerenciadas corretamente e apresentadas com frequência às iterações do produto.

Os principais PMs também reconhecem seu papel na liderança do projeto e, portanto, não esperam que as partes interessadas comuniquem todos os requisitos no início do projeto. Eles entendem que algumas partes interessadas nem sempre sabem como articular suas necessidades, e é seu papel ajudar as partes interessadas a articular suas necessidades, desde a elicitação de requisitos até a entrega do projeto. Também é importante lembrar que, durante o processo de elicitação de requisitos, devemos elicitar não apenas os requisitos das partes interessadas, mas também suas preocupações.

Por exemplo, em organizações menos maduras, um paradoxo interessante costuma acontecer no início de novos projetos. Durante a fase de inicialização do projeto, a equipe de desenvolvimento espera que as partes interessadas identifiquem claramente todos os requisitos e necessidades da solução para a qual desenvolverão. Ao mesmo tempo, as partes interessadas esperam que a equipe de entrega forneça estimativas precisas em tempo e custo.

No entanto, no início da definição do escopo do projeto, há muita incerteza para definir essas estimativas - e, ao fazê-lo, há o perigo de criar estimativas irreais. Às vezes, as partes interessadas incluem tantos requisitos quanto possível, para acomodar a incerteza de uma solução atualmente menos tangível. Enquanto isso, a equipe de entrega fornece uma estimativa muito aproximada para o desconhecido.

O resultado disso provavelmente será uma solução que terá apenas 20% de seus requisitos completos utilizados pelas partes interessadas. O resto será desenvolvido sem um objetivo claro em mente, tornando o projeto acima do orçamento e também do cronograma.

Felizmente, os principais PMs sabem exatamente como envolver as partes interessadas e orientá-las em cada etapa do mundo VUCA (volatilidade, incerteza, complexidade e ambiguidade) de seu projeto. Os gerentes de projeto são capazes de dividir o projeto em incrementos mais tangíveis e envolver as partes interessadas enquanto criam e revisam ativamente os aprendizados.

A principal lição aqui é: “As soluções são criadas para resolver a necessidade de negócios, os PMs precisam garantir que esse objetivo não seja perdido quando o projeto for criado. Certifique-se de que seus stakeholders desejam construir as coisas certas, envolvendo-se com eles para atender às suas principais necessidades e preocupações.”

3. Tornar o gerenciamento de riscos do projeto um exercício orgânico

A maioria dos projetos tem um conjunto de riscos genéricos que são apresentados no início da inicialização do projeto.

Quase todos os projetos começam com esses riscos genéricos, incluindo resistência dos usuários à mudança, falta de recursos e tecnologia imatura, para citar alguns. Os principais PMs engajam suas equipes para identificar não apenas os riscos comuns, mas também os riscos mais urgentes e exclusivos, de modo que a identificação de riscos seja um reflexo ao longo do ciclo de vida do projeto, não uma tarefa trivial no início do projeto.

Ao reconhecer os riscos, os principais PMs também procuram sua colaboração com as principais partes interessadas, que muitas vezes definem o risco de forma explícita ou implícita em seus requisitos e preocupações. Grandes GPs entendem que esse processo acontece desde a etapa de elicitação de requisitos até todo o ciclo de vida do projeto e consideram isso um ativo para definir o risco ao longo do processo.

Os PMs especialistas também confiam em suas equipes e também reconhecem seu conhecimento especializado como uma fonte de mitigação de riscos. Para capacitar os membros da equipe a identificar riscos de forma proativa, o PM capacita sua equipe a se apropriar do projeto e participar ativamente da identificação e gerenciamento de riscos.

Em termos práticos, a terceira pergunta durante uma reunião diária: “O que está atrapalhando?” reflete respostas mais prudentes à medida que uma equipe é capacitada para contribuir para o sucesso do projeto. Obviamente, alguns bloqueadores podem ser temporários ou removidos imediatamente após o scrum, no entanto, alguns são candidatos em potencial que podem se transformar em riscos substanciais. Os membros da equipe precisam ser incentivados a identificar esses riscos potenciais e sua inclusão deve ser celebrada, em vez de desprezada, mesmo no final do ciclo de vida do projeto.

O reconhecimento de risco também não é tão simples quanto declarar o risco e prosseguir. O reconhecimento de risco deve ser avaliado regularmente, em termos de probabilidade, gravidade e uma métrica que às vezes é esquecida: proximidade. A última métrica permite que a equipe defina os itens de ação corretos, seja “Não fazer nada até a próxima etapa de reconhecimento de risco” ou algo mais tangível caso o risco seja mais próximo. O que é importante reconhecer aqui é que os principais PMs entendem como tornar os riscos acionáveis, pois qualquer risco é inútil se não for gerenciado. Além disso, a lista de itens de ação não deve ser apenas reativa, mas também proativa por natureza, informando, em última análise, um Backlog do Produto Ajustado ao Risco.

Em suma, um PM de alto nível reconhece que, independentemente da experiência ou autoridade, eles não são e não devem ser a única fonte de reconhecimento e gerenciamento de riscos. As partes interessadas, sua equipe e outros contribuintes importantes do projeto devem estar envolvidos no reconhecimento e gerenciamento de riscos não apenas durante os estágios iniciais, mas também regularmente ao longo do ciclo de vida do projeto. Isso é importante porque há muito pouco uso dos riscos que foram identificados no início do projeto, mas não foram gerenciados desde então.

A principal lição aqui é: “Para alcançar um gerenciamento de projetos bem-sucedido, toda a equipe deve ser responsável por identificar os riscos. A descoberta de riscos deve ser um processo contínuo que acontece durante toda a vida útil de um projeto.”

4. Entendendo o Meio Ambiente

Um PM de primeira linha não deve começar um projeto como um touro em uma loja na China. Em vez de forçar uma metodologia ou abordagem de projeto, o gerente de projeto deve realizar uma análise aprofundada do ambiente, estrutura formal, estrutura informal, cultura, hábitos, ferramentas, capacidades e ativos organizacionais disponíveis. Só então ele pode iniciar a jornada de mudança.

Embora qualquer PM entenda que os projetos que está realizando terão um impacto na organização, os principais PMs reconhecem que a organização também tem um impacto em seus projetos.

Em vez de uma mentalidade imperfeita, de tamanho único, os principais PMs adaptam sua abordagem entendendo seu ambiente. Ao fazer isso, eles são mais capazes de reconhecer as necessidades de negócios mais urgentes, como as organizações irão adaptar ou aceitar uma solução, adoção e quais mudanças serão feitas na solução para atingir o ajuste certo na entrega dos objetivos.

Ao adaptar uma abordagem eficaz de gerenciamento de projetos, os principais PMs precisam possuir um entendimento profundo de diferentes metodologias, não apenas de diferentes abordagens de PM, mas também de metodologias de análise de negócios, estruturas de gerenciamento de mudanças, estruturas de arquitetura corporativa e outros métodos de análise úteis. Isso dá ao PM a capacidade de encontrar a solução mais adequada para a empresa em questão para entregar o projeto que está realizando.

Por exemplo, se você está iniciando um projeto em uma organização hierárquica extremamente rígida, onde há muitos níveis de aprovação diferentes, a melhor abordagem pode ser uma abordagem de gerenciamento de projetos misto ou híbrido. Você pode realizar uma fase estruturada de elicitação de requisitos, com as aprovações de requisitos feitas antecipadamente e, em seguida, dividindo o projeto em etapas com etapas formais. Em paralelo, o PM pode configurar a execução iterativa do tipo Agile dentro das equipes de desenvolvimento para capturar as melhores práticas do desenvolvimento iterativo, apesar de executar um projeto mais tradicional.

Em resumo, os principais PMs respeitarão a cultura da empresa, enquanto propõem respeitosamente novas abordagens e orientam as organizações a melhorar suas práticas de gerenciamento de projetos. Eles reconhecem que muitas organizações estão em diferentes pontos de maturidade e prontidão para a mudança, e veem isso como uma oportunidade, e não como uma ameaça, para impactar positivamente a capacidade de cada empresa de implementar as melhores práticas de gerenciamento de projetos.

A principal lição aqui é: “Os gerentes de projeto não devem empurrar cegamente sua própria agenda, mas devem se adaptar às formas de trabalho das organizações e entregar a mudança lentamente, se necessário”.

5. Aplicando os Princípios LEAN

Os principais PMs sabem que a jornada importa tanto quanto o objetivo. Às vezes, a jornada do projeto é especialmente complicada por um processo que define como as coisas devem ser feitas. Isso pode tomar forma em modelos desnecessariamente pesados, reuniões inúteis ou periféricos de distração que atrapalham a jornada, mas é sua responsabilidade como PM garantir que esses obstáculos afetem sua equipe o mínimo possível.

Os principais PMs devem identificar processos mais eficientes e eficazes para a equipe, partindo de princípios de gestão ágil de projetos, bem definidos na metodologia LEAN.

Um equívoco popular é que o LEAN é adequado apenas para fabricação, o que simplesmente não é verdade. Os métodos de gerenciamento de projetos LEAN podem aprimorar cada projeto e cada processo. Não é simplesmente um programa de redução de custos, mas sim uma forma de pensar e agir para sua equipe.

Os benefícios da aplicação dos princípios LEAN são bem resumidos por uma citação do CEO da Toyota, Katsuaki Watanabe: “Gerenciamento de processos brilhante é nossa estratégia. Obtemos resultados brilhantes de pessoas comuns gerenciando processos brilhantes. Observamos que nossos concorrentes geralmente obtêm resultados médios (ou piores) de pessoas brilhantes gerenciando processos quebrados.”

Um PM de alto nível com um viés para eliminar ruídos e trabalhos desnecessários do projeto naturalmente conduzirá o processo em direção aos princípios LEAN. Um PM de alto nível deve trabalhar em estreita colaboração com um Product Owner, sua equipe e as partes interessadas relevantes para ajudá-los a simplificar e especificar suas necessidades e o valor esperado como resposta a essas necessidades.

Também é útil olhar além do LEAN para obter as melhores práticas de PM para o seu projeto. Por exemplo, apenas a metodologia PRINCE2 possui uma tarefa obrigatória de capturar as lições aprendidas durante a fase inicial do projeto . Isso captura todas as lições aprendidas dos projetos anteriores, em vez de escrever um documento no final do projeto que raramente será usado por outras pessoas ao iniciar um novo. É importante não ter medo de mudar o processo para eliminar as etapas desnecessárias e focar naquelas que agregam valor real.

Esta é uma boa oportunidade para ajudar e reformular processos, ou para ajudar a equipe a escolher os corretos desde o início. Esses indicadores de desempenho claros devem ser compartilhados de forma transparente com todos os envolvidos para definir um guia claro do sucesso do projeto.

O principal argumento aqui é: “Encontrar as soluções certas é tão importante quanto ter um processo simplificado e correto para fornecer essas soluções”.