Menu
Esqueceu a senha? Fazer cadastro

Gerenciamento de Aquisições ou de Stakeholders?

Sabemos que os contratantes e contratados (compradores e fornecedores) são partes interessadas uns dos outros. Porém, esses relacionamentos nem sempre recebem a atenção que merecem. O resultado pode ser desastroso, como veremos ao longo do post em um caso que resultou em processo judicial. O assunto stakeholders e aquisições está intimamente relacionado com nosso post anterior (“pensar como um gerente de projetos”).

Algumas coisas são difíceis de ensinar. É o chamado conhecimento tácito (know how / knowing), diferente do conhecimento explícito (knowledge). O conhecimento tácito vem da experiência, é o saber fazer. Já o explícito está sistematizado, podendo ser escrito ou não. Por exemplo, conhecimento explícito seria uma receita de como fazer uma torta de maçã. Não sabe como fazer? Vá ler a receita neste link. A receita inclui um passo-a-passo de misturar ingredientes e por aí vai. Mas por que a torta da minha avó fica boa e a minha não, se estamos seguindo a mesma receita?! Por causa do conhecimento tácito, que não dá para tirar da cabeça dela e colocar na sua.

Por isso, não adianta reclamar que as metodologias de gerenciamento de projetos não funcionam. Ler o Guia PMBOK e outros livros somente proporciona conhecimento explícito. É a experiência que vai trazer conhecimento tácito, como colocar em prática Isso envolve pequenas nuances e outras questões contingenciais difíceis de explicar.

Em se tratando do gerenciamento de suprimentos, especificações e aquisições em projetos, a dor de cabeça pode ser ainda maior. Em alguns projetos, existe uma rede de fornecedores com vários níveis (subcontratados). Por outro lado, como defendemos no framework (neste post) de gerenciamento de stakeholders como clientes (livro), é função do gerente do projeto extrair as informações necessárias das partes interessadas.

Recentemente, a Oracle e a Universidade de Montclair chegaram a um acordo em um processo judicial de mais de 3 anos a respeito de um projeto de implantação de ERP (Enterprise Resource Planning) de 2009! Vejam as notícias sobre o caso na Information Week e na Computer World. Obviamente, houveram erros e falhas tanto da parte do cliente (Montclair) quanto do fornecedor (Oracle), pelo que indica o processo judicial. Entretanto, penso que muitas disputas (veja aqui alguns dos maiores fracassos na implantação de ERP) seriam evitadas com um melhor gerenciamento de partes interessadas.

Primeiramente, as responsabilidades precisam ser muito bem definidas. Não existe nada pior do que incerteza, zonas cinzentas. O cliente acha que o fornecedor vai fazer algo, mas o fornecedor acredita que não faz parte das suas responsabilidades fazer esse “algo”.

Captura de Tela 2013-07-24 às 12.44.44

Figura 1 – Fluxo de aquisições a partir do cliente

Atuando na parte do cliente, eu procuro especificar bem o que desejo, de modo que não receba coisas que não quero e também de maneira que não faltem coisas que considero essenciais. Todavia, como percebi ao longo do tempo, os clientes, na grande maioria, desconhecem os detalhes daquilo que estão comprando, o que torna difícil para eles criar uma especificação detalhada.

O caso Montclair vs Oracle ilustra bem isso. A universidade de Montclair tinha um problema, que podemos definir como: desejamos gerenciar efetivamente nossos recursos utilizando um software confiável. Então eles contrataram a Oracle, uma empresa tradicional e respeitada neste mercado. Provavelmente, o pessoal da Montclair não sabia exatamente as implicações que um novo ERP teria, tais como:

  • (re)definição e adequação de processos;
  • funcionalidades necessárias / desejadas;
  • treinamento;
  • infraestrututra, etc.

O pessoal da Oracle, que já realizou vários desses projetos em clientes com maturidades diferentes, deveria saber das dificuldades e orientar o cliente, deixando bastante claro o que faz parte do escopo do projeto e o que não faz. Além disso, a Oracle poderia ter indicado quais seriam as responsabilidades do cliente explicitamente. Como não sei os detalhes, não posso dizer se houve erro ou não nesta parte. O que fica claro pelas reportagens em torno do caso é que cliente e fornecedor passaram a se culpar mutuamente por atrasos, falhas e outros problemas durante a implantação do ERP. Talvez, com uma atitude mais proativa dos gerentes de projetos de ambos os lados, utilizando um gerenciamento efetivo de stakeholders, as organizações tivessem buscado maneiras de colaborar para resolver os problemas, em vez de culparem-se mutuamente.

Outro ponto importante é a escolha do tipo de contrato, ou negócio jurídico bilateral, e suas cláusulas. O tipo e os termos e condições específicas do contrato usado definem o grau de risco que está sendo assumido pelo comprador e pelo fornecedor. Nos projetos, os contratos costumam ser dividos em:

  • Contratos de Custos Reembolsáveis (CR) – Cost reimbursable;

Neste tipo de contrato, os custos do fornecedor são reembolsados, acrescidos de um valor adicional. O comprador tem um grande risco neste tipo de contrato pois se desconhece os custos finais do contrato. Obviamente, é possível incluir incentivos e faixas para limitar os custos mínimo e máximo do contrato.

  • Contratos de Tempo e Material (T&M) – Time and material; e,

Este tipo de contrato se baseia em um custo por unidade (hora, material etc). Ele apresenta elementos de um contrato de preço fixo (no preço fixo por unidade) e elementos de contratos de custos reembolsáveis (o custo total é desconhecido, embora possa ser colocado um limite).

  • Contratos de Preço Fixo (PF) – Fixe Price (FP).

Costuma ser tipo de contrato mais comum. Neste tipo de contrato um preço fechado é acordado para o projeto como um todo. É um contrato de grande risco ao fornecedor, pois se existirem custos adicionais terão que ser assumidos por ele. Por outro lado, se o cliente não especificar bem aquilo que deseja, terá grandes problemas (risco). Já nos contratos de custos reembolsáveis, é possível fazer mudanças nas especificações ao longo do tempo, enquanto que nos contratos de preço fixo as alterações geralmente envolvem aditivos.

Captura de Tela 2013-07-24 às 12.54.50

Figura 2 – Modalidades de contrato

Finalmente, vale a pena revisitar a figura abaixo sobre o gerenciamento de stakeholders.

stk-1

Figura 3 – Gerenciamento dinâmico de stakeholders

Infelizmente, chegamos ao final do post. É um assunto interessantíssimo e que demanda mais tempo e conteúdo. Além disso, é extremamente importante para os gerentes de projetos conhecer os aspectos importantes dos contratos, já que estarão envolvidos e sujeitos à eles (eu, particularmente, resolvi fazer Direito depois da graduação em Engenharia…). Voltaremos ao gerenciamento de aquisições em outros posts. Até lá!

Pense como um Gerente de Projeto

Amigos leitores, no último post, conversamos sobre Ética, um assunto extremamente importante em qualquer carreira profissional. Para aqueles que desejarem saber um pouco mais sobre Ética e a Complexidade Cultural, recomendo fortemente que assitam este vídeo.

Nesta semana, assisti a uma palestra do Sr. Te Wu, diretor do NYC Chapter, sobre o que é ser um gerente de projetos. Os desafios atuais demandam atenção para novas dimensões em projetos, incluindo o contexto organizacional, cultural, de mercado e relacionamentos externos. Alinhamento estratégico, gerenciamento de riscos e governança formam a sustentação de uma boa metodologia de gerenciamento de projetos, que precisa ser customizada para cada organização.

Captura de Tela 2013-07-15 às 14.36.22Figura 1 – Project management dimensions (WU, Te., 2013)

Entretanto, o que mais chamou a atenção foi o Sr. Te Wu dizer que não basta ter o conhecimento e as ferramentas nem a experiência em gerenciamento de projetos. Esse foi um ponto enfatizado repetidamente durante a palestra e eu concordo muito com ele.

Além da discussão em torno de stakeholders, ética e diferenças culturais, conversamos sobre a importância de estabelecer um mindset ou modo de pensar flexível e adaptativo para nos desenvolvermos na carreira de gerenciamento de projetos. Isto é, segundo Wu, é preciso pensar e sentir como um gerente de projetos, algo que envolve mais do que gerenciar a famosa tripla restrição (Veja esse .pdf – PM Tech).

Captura de Tela 2013-07-15 às 14.36.41Figura 1 – How to think like a project manager (WU, Te., 2013)

Em essência, gerenciar projetos hoje envolve complexidade, volatilidade e velocidade nas mudanças. Para lidar com esse novo ambiente, que já discutimos em alguns outros posts no Blog MundoPM, o Sr. Te Wu propõe que o gerente de projetos deve pensar e agir em seis principais vertentes:

  • Balanço: envolve equilibrar as demandas conflitantes sob a perspectiva do que é melhor para o projeto como um todo, isto é, anlisar os trade offs à luz do resultado final.
  • Trabalho em Equipe: são pessoas que executam o trabalho do projeto, o gerente é o maestro e líder. Sem a equipe, nada é possível de ser feito. Respeite as pessoas e obtenha o respeito delas, essa é a chave do sucesso.
  • Pensamento Holístico: nenhum projeto está alheio ao seu ambiente. O contexto da organização envolve o projeto e tem grande influência sobre ele. É preciso compreender e analisar o projeto dentro da estratégia organizacional, considerando os fatores políticos, sociais e culturais da empresa.
  • Visão Global: considera que o mundo está cada vez mais interconectado. Globalização já é um termo bastante surrado, mas a vigilância tecnológica e a inteligência de mercado são dois pontos bem importantes para boa parte dos projetos realizados atualmente no mundo.
  • Realismo: seja realista, não seja excessivamente otimista nem pessimista. Bom planejamento e estimativas são um excelente começo. Obviamente, o plano é flexível e pode mudar. Às vezes, também é preciso ser cético. Confronte os problemas, issues, efetivamente. Não deixe os desvios se acumularem.
  • Incentivos: é preciso conhecer bem seus stakeholders, suas expectativas e desejos, algo que discutivos em alguns posts anteriores.

Certamente, seguindo as orientações acima, você será capaz de gerenciar os principais aspectos do projeto sob as perspectivas de diferentes stakeholders. Além disso, cuidar da sua equipe é primordial. E as qualidades mais importantes de um líder são honestidade e respeito. Com isso, podemos construir uma reputação sólida, algo que é observado e testado pelos seguidores, equipe e demais stakeholders a todo tempo.

Continuando o assunto destes dois últimos posts, na próxima semana vamos falar de gerenciamento de aquisições e disputas contratuais. Quais são os tipos de contratos? Quais as vantagens e desvantagens de cada um? Quem são meus stakeholders? Como evitar disputas judiciais e outros problemas envolvendo contratação e aquisição em projetos? Não percam!

Ética deveria ser uma área do PMBOK?

Aproveitando essa onda de manifestações pelo Brasil, eu gostaria de fazer algumas considerações sobre ética, algo que está bastante em falta, não é? Obviamente, não é privilégio do Brasil nem se circunscreve apenas à classe política, é um problema generalizado que deve ser atacado frontalmente. Não adianta esconder, dar “jeitinho”, tornar os limites mais “elásticos” ou se aproveitar de “zonas cinzentas”. Para vocês terem uma idéia, colocando “Ética” no Google, encontramos mais de 44milhões de referências… ainda assim, não conseguimos encontrar muitos exemplos como “policial rejeita R$1milhão de propina e prende traficante“. Ou seja, muita teoria de ética e poucos exemplos.

imagesPenso que estamos vivendo não apenas um “apagão de talentos” mas também um apagão de ética no Brasil e no mundo, onde os fins sempre justificam os meios. É preciso valorizar comportamentos como a Disciplina Consciente, que significa jogar corretamente as regras do jogo, sem trapacear. A atitude ética e o comportamento ético deveriam ser parte do íntimo de cada um de nós. Infelizmente, não é o que observamos. Por este motivo, várias empresas possuem códigos de ética e códigos de conduta, bem como organizações de classe (CREA e outras) e outras associações.

Inclusive,o Project Management Institute também possui um Código de Ética e Conduta Profissional (faça o download do .pdf aqui).

Engraçado que a maioria dos aspirantes a PMP / CAPM consideram ética como a parte mais chata e / ou difícil do exame. São perguntas que envolvem desde uma postura diante de conflitos de interesse até o comportamento ilegal ou criminoso. Por exemplo, será que existe um conflito de interesses se eu contratar a empresa de um amigo meu ou parente para ser fornecedor da empresa para a qual eu trabalho? Digamos que a minha empresa necessite de serviços de logística e o meu amigo, dono de um operador logístico, está me oferecendo o mesmo preço, ou pouco menos, que o meu fornecedor atual. Posso contratá-lo? Bem, eu posso. Porém, é preciso sinalizar para as pessoas da minha organização, especialmente meus superiores, controle interno e afins. Por que? Se o meu amigo está fazendo um preço melhor, qual é o conflito? O conflito é que você pode precisar negociar com ele ao longo do contrato, você pode precisar multá-lo, reclamar dos serviços e assim por diante.

Imagine que o seu irmão é o fornecedor de serviços de logística para a empresa em que você trabalha. Se no final de 2013 tivermos uma crise e sua organização precisar cortar custos, você vai dispensar a empresa do seu irmão ou vai tentar cortar custos em outras áreas? Vai tomar essa decisão considerando o que é melhor para a sua empresa ou balanceando com a preocupação em relação ao seu irmão, ou amigo? Sempre que possa haver algum tipo de favorecimento ou parcialidade, existe um conflito de interesses. E isso precisa ser endereçado corretamente para evitar problemas futuros.

images-1Outro problema comum é o pensamento de que “os fins justificam os meios”.    Essa é outra área que traz grandes dificuldades nas questões de ética e   conduta. Suponha que você burlou um procedimento de segurança da sua   empresa para agilizar uma operação cujo resultado foi excelente, lucrativo etc. Você seria um herói, certo? Mais ou menos. Pode ter dado certo por pura    sorte. E, se tivesse dado errado, os resultados poderiam ser catastróficos… já pensou nisso?

Finalmente, existe outra coisa que nos afasta da ética: complacência. Fazer   vista grossa ou fingir que não viu, não está vendo, um comportamento não-ético de outra pessoa é equivalente a ser partícipe ou testemunha. É falta de ética. Não basta eu ser ético, comportando-me corretamente. Se eu não assumir a responsabilidade por propagar essa ética e zelar por ela, pouco adianta. Eu não roube a minha empresa, mas vejo uma pessoa cometendo desvios e não a denuncio, não a repreendo nem converso com ela. Neste caso, não posso me considerar alguém realmente ético, certo?

Amigos leitores, o problema da ética é que muita gente confunde com bom senso; e bom senso é algo que todo mundo acredita que tem. Eu não acho que a ética deveria entrar como uma área do Guia PMBOK, porém o Código de Ética do PMI deveria ser mais rigorosamente aplicado. Aliás, todos os códigos de ética e conduta profissional das associações de classe, empresas e outras organizações deveriam ser melhor aplicados. De palavras bonitas, nossos livros, murais e manuais estão cheios. Falta colocar em prática. E, se queremos mudar alguma coisa no mundo ao nosso redor, essa mudança precisa começar em nós.

imgresSeja a mudança que você quer ser no mundo. Dalai Lama.

Vale a pena ler este texto sobre ética, de Leonardo Boff. Para refletir, logo abaixo, temos um texto muito bacana, retirado do site do PMI Brasil:

No ambiente empresarial, atuar e comportar-se de forma ética nunca foi tão importante quanto nos dias de hoje. O Instituto de Gerenciamento de Projetos (PMI) acredita na importância e na criticidade de um comportamento ético na profissão de gerenciamento de projetos. Cada vez mais os profissionais enfrentam dilemas éticos ao longo de suas carreiras, porém, a forma de agir diante desse tipo de situação nem sempre é clara. Por conta disso, o PMI oferece guias como o Código de Ética e de Conduta Profissional aos profissionais, assim como um caminho para relatar e resolver questões que envolvam um comportamento não-ético através de um Comitê de Ética.

O PMI fornece links para as ferramentas e recursos necessários para auxiliar os profissionais de gerenciamento de projetos a avaliar sua situação e fazer seu julgamento ético da melhor forma possível.

Veja o vídeo Ética e Você (em inglês) para maiores informações sobre o Código de Ética e de Conduta Profissional, e para saber como o Código pode orientá-lo quando você estiver diante de um dilema ético.

No próximo post, voltaremos com mais assuntos práticos sobre gerenciamento de projetos. Até lá!

A abordagem Lean sob a perspectiva do Gerenciamento de Programas e Projetos

A abordagem Lean sob a perspectiva do Gerenciamento de Programas e Projetos

Para iniciar minha colaboração para o Blog da Revista Mundo PM, neste primeiro post vou descrever uma visão geral sobre o conceito Lean em programas e projetos. Obviamente, este assunto é complexo e para aqueles que desejam conhecer mais sobre o tema eu sugiro a leitura das referências indicadas no final deste post, mas também buscarem referências complementares.

Recentemente, foi publicado um artigo na revista PM Network do Project Management Institute – PMI, Junho/2013, cujo título da capa é: “Cut waste, save Money: The Lean Enablers Equation”. O artigo coleta experiências de profissionais que de certa forma estiveram envolvidos com práticas Lean em programas e projetos e também especialistas a área como o pesquisador Dr. Josef Oehmen, do MIT. Oehmen é o autor do guia que descreve um conjunto de facilitadores e práticas Lean voltadas para programas de engenharia, chamado The Guide to Lean Enablers for Managing Engineering Programs (Oehmen, 2012), cuja referencia completa está no final deste post.

O artigo está disponível para acesso no link: http://www.pmi.org/Knowledge-Center/Publications-PM-Network.aspx.
edivandro_image002

Um dos principais desafios de qualquer organização que desenvolve programas e projetos é a redução de desperdícios de toda ordem, seja o tempo gasto com reuniões improdutivas ou evitar o retrabalho para concertar erros de projeto que podem impactar o desempenho do produto final. A necessidade de se reduzir desperdícios é proporcional ao tamanho do programa, projeto. Quanto maior o programa maior será a necessidade de se reduzir desperdícios, pois haverá um maior fluxo de recursos, mais profissionais envolvidos, fornecedores, parceiros, etc., tornando o programa complexo de ser gerenciado.

Nesse contexto, os termos “adicionar valor para o cliente e para o negócio”, “reduzir desperdícios”, “reduzir custos”, “aumentar a eficiência”, “entregar resultados com maior qualidade e velocidade” são conhecidos por todo e qualquer gerente de projeto ou gestor de um programa. Lean não se trata exclusivamente de redução de desperdícios, porém neste post irei falar um pouco mais sobre este aspecto do gerenciamento de programas e projetos.

De acordo com o artigo da PM Network é importante identificar as fontes de desperdícios no programa. Algumas fontes de desperdícios são: planejamento inadequado; problemas na comunicação em todos os níveis, desde os próprios membros do time de projeto até os stakeholders e os diversos níveis gerenciais em uma organização; e deficiência na entrega de resultados, por exemplo, atendendo critérios clássicos segundo a gestão de projetos (qualidade, prazo, custo, escopo). Tais fontes de desperdício são apenas exemplos. É preciso considerar as características peculiares de cada programa e seu contexto.
Conforme descrito no “The Guide to Lean Enablers for Managing Engineering Programs” (Oehmen, 2012 ), existem 10 desafios que contribuem para a ineficiência e desperdícios no gerenciamento de programas de engenharia (Oehmen, 2012, p.28, Figura 10). São eles:

  • Execução reativa do programa
  • Requisitos do produto instáveis, pouco claros ou incompletos
  • Alinhamento e coordenação insuficiente entre o programa e as demais áreas da organização
  • Processos otimizados localmente que não estão integrados com os demais processos da organização
  • Papéis e responsabilidades pouco definidas
  • Gestão deficitária da cultura do programa, competências e conhecimento dos membros da equipe de execução
  • Planejamento insuficiente do programa
  • Uso de métricas, sistemas de medição e indicadores de desempenho inadequados para o programa em desenvolvimento
  • Ausência de uma gestão de risco pró-ativa no programa
  • Práticas de aquisição e contratação pouco eficientes

Algumas técnicas podem ajudar nesse trabalho de identificação dos desperdícios e atividades que não agregam valor ao programa ou projeto. Por exemplo, pode-se utilizar técnicas de modelagem de processos, mapeamento do fluxo de valor (ou VSM – Value Stream Mapping), dentre outras.

Sobre o Guia: O Guia é um trabalho colaborativo entre MIT/LAI (http://lean.mit.edu/), PMI (http://www.pmi.org/)  e INCOSE (http://www.incose.org/). No guia está uma lista com 10 desafios na gestão de programas; 43 Facilitadores Lean e 286 sub-fatores Lean. Os facilitadores e sub-facilitadores estão organizados em 6 grupos, que são os princípios Lean. O Guia está disponível para download gratuito neste link.

edivandro_image005

Em seguida, é necessário compreender como os Facilitadores/Práticas Lean podem ser combinadas e integradas no processo de gestão do programa ou projeto. É importante conhecer os princípios Lean e como podem ser adaptados, “moldados” para atender as necessidades do gerenciamento de programas e projetos. O Guia traz um conjunto de 6 princípios Lean, com 43 facilitadores e 286 sub-facilitadores segundo a perspectiva do gerenciamento de programas. Os 6 princípios Lean descritos no Guia são (Oehmen, 2012, p.13):

  • Construir uma cultura no programa de respeito às pessoas;
  • Identificar/capturar o valor definido pelo cliente e stakeholders;
  • Mapear o fluxo de valor e eliminar desperdícios;
  • Desenvolver o fluxo de trabalho por meio de processos planejados e eficientes;
  • Trabalhar para que os clientes puxem o valor;
  • Buscar a perfeição em todos os processos.

Construir uma cultura no programa de respeito às pessoas é um princípio chave destacado no artigo da PM Network. As pessoas são consideradas o alicerce de toda organização, programa ou projeto, por isso é importante:

  • Dar uma visão concreta dos objetivos a serem alcançados;
  • Reconhecer o potencial do time para resolver problemas complexos;
  • Reconhecer o potencial do time para participar da tomada de decisão;
  • Escutar o time e dar feedback, sempre que houver uma mudança;
  • Promover um ambiente de trabalho que possibilite o aprendizado e crescimento;
  • Confiar na capacidade do time para entregar os resultados estabelecidos.

Existem inúmeros outros aspectos que poderiam ser considerados quando falamos das pessoas envolvidas em um programa ou projeto. Esses seis aspectos, que acabei de relatar brevemente, estão refletidos em um dos 12 princípios do “Manifesto for Agile Software Development” que é uma referência para a abordagem de Gerenciamento Ágil de Projetos, e cujo foco tem sido desenvolver competências para que os times de projeto sejam mais “ágeis”, por meio da adoção de práticas específicas e a existência de fatores contextuais adequados. O princípio* é descrito como: “Construa projetos em torno de indivíduos motivados. 
Dê a eles o ambiente e o suporte necessário 
e confie neles para fazer o trabalho”.

Portanto, se sua organização deseja conhecer mais e implementar os princípios Lean e buscar melhor desempenho e redução de desperdícios no gerenciamento de programas ou projetos, pode começar entendendo melhor como esta abordagem surgiu e como pode ser útil. Em especial os princípios e como eles podem ser integrados à estratégia da organização. Como toda melhoria de processo ou mudança na forma de trabalho, na cultura, este é um processo árduo e de longo prazo.

Gostaria de indicar alguns livros sobre o assunto que podem ajudar no entendimento dos conceitos Lean e na definição de ações de melhoria em sua organização. Inicialmente, podem ler o artigo da revista PM Network, e o Guia citados neste texto. Adicionalmente, sugiro três livros que são considerados referência no tema. O primeiro é o livro escrito por Morgan e Liker (2006) com o titulo “The Toyota Product Development System. Outra importante referência para se compreender o conceito Lean é o livro de Womack e Jones (2003) com o nome Lean Thinking: Banish Waste and Create Wealth in Your Corporation. Um terceira referência interessante é o livro do James Womack “Maquina que Mudou o Mundo.

Boa leitura!

 

Referências bibliográficas:
OEHMEN, J. (Ed.). 2012. The Guide to Lean Enablers for Managing Engineering Programs, version 1.0. Cambridge, MA: Joint MIT-PMI-INCOSE Community of Practice on Lean in Program Management. URI: HTTP://hdl.handle.net/1721.1/70495.

*Este princípio foi extraído da versão em português do “Manifesto for Agile Software Development”, disponível em: http://agilemanifesto.org/iso/ptbr/principles.html. O equivalente em inglês pode ser consultado no link: http://agilemanifesto.org/principles.html

Organizações clamam por melhores líderes de projetos, mas ainda investem mais em habilidades técnicas.

por LeRoy Ward – Vice-Presidente da ESI

Sem títuloPsicólogos e profissionais de aprendizagem têm um termo interessante que eles usam quando as coisas estão, em minha opinião, “fora de sintonia.” Eles chamam isso de dissonância cognitiva. Aqui está um exemplo. Você está em uma conversa com a sua “cara-metade” e diz algo que irrita ele ou ela. Você reconhece sua raiva e diz “não fique bravo.” Ele ou ela te olha diretamente nos olhos e grita “Eu não estou bravo”! É claro que está, mas não veem isso dessa forma. Isso é a dissonância cognitiva.

E a dissonância cognitiva nas organizações e no trabalho?

As organizações também são assim quando se trata de treinamentos para Gerentes de Projetos. Nós ouvimos e lemos muito sobre como executivos, líderes de PMO e diretores de unidades de negócios reclamam que seus Gerentes de Projetos carecem de habilidades de negócios e lideranças. Eles apontam esta deficiência como um dos principais motivos pelos quais muitos projetos falham completamente ou apresentam problemas.

No entanto, recentes pesquisas da ESI descobriram que há mais gasto no desenvolvimento de habilidades específicas de gerenciamento de projetos do que em desenvolvimento de liderança ou habilidades interpessoais (soft skills).
Isto é uma dissonância cognitiva no nível organizacional não é? Se as organizações precisam de gestores de projetos com forte habilidade de liderança, então por que deixam de investir nesta área? Uma boa pergunta não é mesmo?

Uma razão para isso torna-se relativamente clara quando você tem uma conversa com algumas dessas pessoas que estão lamentando sobre a situação. Parece que toda grande organização tem a sua própria gestão e um programa de desenvolvimento de liderança. Eles variam, é claro, mas normalmente é dividido em três áreas: formação de supervisão, desenvolvimento gerencial e de liderança executiva. Este tipo de treinamento e desenvolvimento é também da competência do RH que defende e protege sua área.

E por que os programas de desenvolvimento de liderança são protegidos com muito cuidado por seus “cuidadores”? É porque muitas organizações têm seus próprios modelos de competências que se aplicam de forma ampla para vários níveis de gestão, e eles não querem programas de liderança apresentados aos seus colaboradores que não se alinham com esses modelos. Faz sentido.

Mas muitas vezes, o modelo de competências para um gerente geral não é aplicável para um gerente de projeto. Afinal de contas, embora haja muita sobreposição em habilidades de liderança, gerenciamento de projetos é diferente de administração geral e, como tal, requer habilidades diferentes que muitas vezes não são abordados no treinamento de liderança geral.

Eu já recebi feedback de mais de um executivo de projeto que o que eles precisam é de desenvolvimento de liderança que seja específico para o papel de gerente de projetos e/ou programas.

A menos que ou até que o RH e o PMO trabalhem em conjunto para chegar a um cenário que reconheça a diferença entre gestão e gestão de projetos, vamos sempre ver mais GPs ( Gerentes de Projetos ) que estão sendo treinados muito mais para construir um WBS do que para construir uma equipe de alta performance.