Ouça a versão em áudio deste artigo
Ser um PM top faz você se destacar e se você for reconhecido como um top PM , 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 principais 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. Com sorte, eles o ajudarão a se tornar um ou a verificar se você já tem esses hábitos à sua disposição.
A confiança é um aspecto importante de cada equipe. É frequentemente falado e escrito sobre ele, 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 até mesmo por uma variedade de diferentes organizações de gerenciamento de projetos.
A International Project Management Association acaba de incluir seções sobre confiança em seus Certificação ICB4 que é o padrão global para competências individuais em gerenciamento de projetos, programas e portfólio.
Similarmente, 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 do projeto empírico. 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 tópico urgente por tanto tempo, quais são os principais bloqueios que impedem os PMs de estabelecer confiança real em suas equipes?
Uma das respostas mais recorrentes a essa pergunta é 'cultura de 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 realidade, os GPs devem facilitar o ambiente certo de transparência e conforto dentro de suas equipes, uma vez que a maioria das pessoas tem um desempenho muito melhor em um ambiente onde os membros da equipe são capazes de se expressar e cometer erros.
Um PM importante ensina a sua equipe esses princípios pelo exemplo, vivendo ao lado deles, incentivando-os a compartilhar seus erros e transformando-os em exemplos de aprendizagem. 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 ficar na defensiva ou transferir a culpa. Explicando que você cometeu um erro e porque pode fazer você se sentir vulnerável, mas se você admitir abertamente e analisar esses erros, esse hábito ajudará outras pessoas a evitá-lo no futuro e ajudará a todos a construir confiança e se abrir sobre seus deslizes. Por exemplo, se você prometer exageradamente a uma parte interessada principal que conclua um marco antes do possível, devido à falta de profundidade técnica que você tinha desse assunto, aceite admitir seu erro para a equipe e deixá-los saber que você errou ao invés de culpar eles por não fornecerem a tecnologia tão rápido quanto você gostaria. Isso pode inspirar outras pessoas a abrir e construir conexões mais fortes com você e seus colegas de equipe.
Entenda os membros de sua equipe: suas capacidades, medos, frustrações, do que gostam ou não gostam e como interagem com outras pessoas. Quando os membros da equipe sentem que são valorizados, eles agregam valor com mais facilidade. Encontre maneiras de motivar sua equipe com a tarefa em questão, em vez de forçá-los a atingir seus objetivos. Para fazer isso, descreva claramente o que significa sucesso para o projeto e as funções e responsabilidades da equipe do projeto, mas deixe-os ser especialistas em suas áreas. Espere que os membros da sua equipe 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ê interagir. Muitos PMs cometem erros ao mergulhar direto nas tarefas de redação e assumir essa responsabilidade por conta própria. Isso às vezes acontece devido à falta de confiança e compreensão dessas equipes. Quando você tiver a confiança de sua equipe, certifique-se de que eles se envolvam na definição do escopo do trabalho, escrevendo histórias de usuários e, em geral, aconselhando você sobre os assuntos que consideram importantes.
Os principais PMs percebem que sua equipe é seu melhor ativo e aproveitarão todas as oportunidades para construir relacionamentos sólidos 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 por alguém acima. Este é o precursor de algumas das dicas mais técnicas deste artigo, pois, sem essa confiança, seu projeto provavelmente enfrentará uma série de problemas.
Conclusão: “Não há problema em mostrar que todos cometem erros. Compartilhe seus erros ao cometê-los, mostre à sua equipe que você está do lado dela e faça da confiança dentro de sua equipe uma prioridade. ”
Como PM, você provavelmente está ciente do fato de que muitos projetos de software acabam entregando algo diferente do que os stakeholders 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 de 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 às reais necessidades do negócio.
Em conjunto com 'por que', os principais gerentes de projetos devem pedir um acompanhamento de 'para quem?' Quais partes interessadas estamos apoiando, a fim de entregar a solução, para cobrir seu 'por quê?'
É aqui que um gerente de projetos de ponta reconhece uma distinção importante. A solução pode ser definida como uma saída ou entrega, mas um PM de topo entende que qualquer solução em si não cobrirá necessariamente a necessidade original do negócio. Por exemplo, se as partes interessadas pensam 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 próprio ERP é 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 seus objetivos ﹣ criar soluções que impactam as metas de negócios ﹣ as responsabilidades do gerente de projeto vão além da própria criação da solução, para onde as soluções vão ao ar, medindo claramente se o valor efetivamente 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, as metas de negócios são esquecidas no meio do desenvolvimento e das mudanças de requisitos. Freqüentemente, os projetos acabam entregando produtos funcionais, que resolvem algumas, mas não todas as necessidades reais de negócios que inicialmente motivaram o desenvolvimento do produto. Isso pode ser evitado se as partes interessadas forem gerenciadas corretamente e apresentadas com iterações de produto com frequência.
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, temos que extrair não apenas os requisitos das partes interessadas, mas também as suas preocupações.
Por exemplo, em organizações menos maduras, um paradoxo interessante geralmente acontece no início de novos projetos. Durante a fase de inicialização do projeto, a equipe de desenvolvimento espera que os stakeholders identifiquem claramente todos os requisitos e necessidades da solução para a qual irão se desenvolver. Ao mesmo tempo, as partes interessadas esperam que a equipe de entrega forneça estimativas precisas em termos de tempo e custo.
No entanto, no início da definição do escopo do projeto, há muita incerteza para definir essas estimativas - e, ao fazer isso, 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, fazendo com que o projeto ultrapasse o orçamento e também o 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 ambigüidade) 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 ativamente criam e revisam os aprendizados.
A principal lição aqui é: “As soluções são construídas para resolver a necessidade do negócio, os PMs precisam garantir que essa meta não seja perdida quando o projeto for criado. Certifique-se de que suas partes interessadas desejam construir as coisas certas, envolvendo-se com elas para atender às suas principais necessidades e preocupações. ”
A maioria dos projetos tem um conjunto de riscos genéricos que surgem no início da inicialização do projeto.
Quase todo projeto começa com esses riscos genéricos , incluindo a resistência dos usuários à mudança, falta de recursos e tecnologia imatura, para citar alguns. Os principais PMs envolvem suas equipes para identificar não apenas os riscos comuns, mas também os riscos mais urgentes e exclusivos, de forma que a identificação dos riscos seja um reflexo em todo o ciclo de vida do projeto, não uma tarefa servil no início do projeto.
Ao reconhecer os riscos, os principais PMs também buscam sua colaboração com as principais partes interessadas, que geralmente definem o risco de forma explícita ou implícita em seus requisitos e preocupações. Grandes PMs entendem que esse processo acontece desde a etapa de elicitação de requisitos até todo o ciclo de vida do projeto, e consideram isso como um ativo para definir o risco em todo o 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 assumir a responsabilidade pelo projeto e participar ativamente da identificação e gestão de riscos.
Em termos práticos, a terceira pergunta durante uma trocação diária, 'O que está atrapalhando?' reflete respostas mais prudentes, pois uma equipe tem poderes para contribuir para o sucesso do projeto. Claro, alguns bloqueadores podem ser temporários ou removidos imediatamente após o scrum, no entanto, alguns são candidatos potenciais 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 menosprezada, mesmo no final do ciclo de vida do projeto.
O reconhecimento do risco também não é tão simples quanto declarar o risco e prosseguir. O reconhecimento de riscos deve ser avaliado regularmente, em termos de probabilidade, gravidade e uma métrica que às vezes é esquecida: a proximidade. A última métrica permite que a equipe defina os itens de ação corretos, seja “Não faça nada até a próxima etapa de reconhecimento do 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 pró-ativa por natureza, informando, em última análise, um Backlog do Produto Ajustado ao Risco.
Resumindo, um PM de alto escalão reconhece que, independentemente de 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 durante o ciclo de vida do projeto. Isso é importante porque há muito pouco uso de riscos que foram identificados no início do projeto, mas não foram gerenciados desde então.
A principal lição aqui é: “Para obter um gerenciamento de projeto bem-sucedido, toda a equipe deve ser responsável por identificar os riscos. A descoberta de risco deve ser um processo contínuo que acontece durante toda a vida útil de um projeto. ”
Um gerente geral não deve iniciar 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 profunda 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 tem um impacto semelhante em seus projetos.
Em vez de uma mentalidade falha e de tamanho único, os principais PMs adaptam sua abordagem ao compreender 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 se 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 de gerenciamento de projeto eficaz, os principais PMs devem possuir um conhecimento 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 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 mista ou híbrida de gerenciamento de projetos. Você pode realizar uma fase estruturada de elicitação de requisitos, com as aprovações de requisitos feitas com antecedência e, em seguida, dividindo o projeto em estágios com portas de estágio formais. Paralelamente, o PM poderia configurar a execução iterativa do tipo Agile dentro das equipes de desenvolvimento para capturar as melhores práticas de desenvolvimento iterativo, apesar de executar um projeto mais tradicional.
Em resumo, os principais PMs respeitarão a cultura da empresa, ao mesmo tempo que proporão novas abordagens e orientarão 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 mudanças e veem isso como uma oportunidade, em vez de 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.”
Os principais PMs sabem que a jornada é tão importante quanto o objetivo. Às vezes, a jornada do projeto se torna especialmente complicada por um processo que define como as coisas devem ser feitas. Isso pode assumir a forma de modelos desnecessariamente pesados, reuniões inúteis ou periféricos 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 gerenciamento de projetos ágeis, bem definidos na metodologia LEAN.
Um equívoco popular é que LEAN é adequado apenas para manufatura, o que simplesmente não é verdade. Os métodos LEAN de gerenciamento de projetos 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 costumam obter resultados médios (ou piores) de pessoas brilhantes gerenciando processos interrompidos. ”
Um PM superior com uma tendência para eliminar o ruído e trabalho desnecessários do projeto irá naturalmente conduzir o processo aos princípios LEAN. Um PM superior deve trabalhar em estreita colaboração com um Dono do Produto, sua equipe e partes interessadas relevantes para ajudá-los a otimizar e especificar suas necessidades e o valor esperado como uma resposta a essas necessidades.
Também é útil olhar além do LEAN para pegar emprestadas 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 o fase inicial do projeto . Isso captura todas as lições aprendidas com os 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 remodelar 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 de sucesso do projeto.
A principal lição aqui é: “Encontrar as soluções certas é tão importante quanto ter um processo otimizado e correto para entregar essas soluções.”
1. Construir confiança em sua equipe. 2. Engajar seus stakeholders para obter o que realmente precisam. 3. Fazer do gerenciamento de riscos do projeto um exercício orgânico. 4. Compreender o meio ambiente. 5. Aplicação dos princípios LEAN
Os principais PMs devem identificar processos mais eficientes e eficazes para a equipe, partindo de princípios bem definidos na metodologia LEAN.
Um equívoco popular é que LEAN é adequado apenas para manufatura, o que simplesmente não é verdade. Os métodos 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.