O Sim, O Não e O Talvez

Por Giovani Faria

Enquanto gerente de projetos você deve ser frequentemente questionado, por exemplo:

  • a aceitar novos desafios (projetos para gerenciar)
  • a dar seu parecer/opinião sobre determinado assunto (problema) relacionado ao projeto
  • a fornecer sua visão de como pode (ou deve) ser o andamento do projeto
  • etc.

Assim, em um ambiente dinâmico de gerenciamento de projetos (projetos, portfólios e programas) a gama de demandas deve ser praticamente ‘infinita’, ou então, ser acima de sua capacidade física-mental-temporal de gestão.

Pois bem, quer seja nas ‘condições normais de temperatura e pressão – CNTP’, ou neste contexto onde você pode ser chamado a atender demandas prioritárias (ou urgentes) para a organização que representa, uma simples resposta SIM ou NÃO pode (e provavelmente, vai) fazer toda a diferença.

Existem vários posts na blogosfera ‘ensinando’ ao GP como dizer NÃO para diferentes ‘entidades’, como por exemplo:

  • a organização onde trabalha: rejeitando um novo trabalho ou um recurso (humano, infra, etc) para um projeto em andamento.
  • o sponsor do projeto: rejeitando o prazo estipulado para o projeto ou o orçamento previsto.
  • o cliente: negando atender a alguma demanda que possa provocar algum distúrbio no andamento do projeto (ou favorecer a ocorrência de um risco em potencial).
  • o time: barrando um pedido de férias, promoção, etc.

Novamente, as circunstâncias são várias e as consequências desse negativa (desse NÃO) podem ser catastróficas, senão, fontes de grandes dores de cabeça e longas discussões (e reuniões).

Por outro lado, simplesmente aceitar (dizer SIM) não é garantia da ausência de cefaléia e da necessidade, novamente, de muita conversa (e negociação) para deixar tudo nos trilhos novamente. Esse ‘inofensivo’ SIM pode, por exemplo, demandar um replanejamento de uma porção grande do projeto (já que você, por exemplo, teria aceitado antecipar uma entrega futura).

O TALVEZ parece, num primeiro momento, ser uma reposta um tanto quanto neutra, ou mesmo extremamente vaga e evasiva. Além disso, dependendo da maneira como é esta resposta é colocada na discussão pode ser, imediatamente, entendida como um SIM ‘disfarçado’, ou então, como um NÃO ‘cauteloso’.

O TALVEZ deve ser utilizado como uma estratégia de ganhar um pouco mais de tempo para a análise e coleta de informações e deve sempre vir acompanhado de um plano de ação. Por exemplo, a resposta poderia ser: “Vou verificar a informação xyz e solicitar uma posição do departamento xpto. Depois disso, até o meio da próxima semana, vou agendar uma reunião para fecharmos o assunto e decidir pela sua continuidade (SIM) ou NÃO.”.

Neste contexto, o TALVEZ é a ‘saída pela direita’, um subterfúgio estratégico para lhe permitir analisar melhor e ter mais dados, parâmetros e segurança para decidir (mesmo porque, em alguns casos, essa decisão pode exceder seu limite de autoridade e de responsabilidade).

Agora, embora você possa estar na posição da vidraça, onde é o alvo da maioria (senão de todas) as demandas, um bom artifício é procurar ‘virar o jogo’ a seu favor. Ou seja, com cuidado, lógica e estratégia, procurar fazer também perguntas, questionamentos e solicitações que, embora sejam pertinentes e visem atender de maneira mais completa (e profissional) a demanda inicialmente recebida, acaba por lhe proporcionar uma condição onde o lado requisitante, mesmo sendo a origem do ‘problema’ (demanda), é chamado a participar de forma ativa na solução.

Resumindo: o GP não deve, necessariamente, dizer SIM para tudo. Nem tampouco, dizer NÃO sempre. Pode até usar o TALVEZ como estratégia para ganhar tempo (e usar suas competências analíticas de forma mais estruturada). Entretanto, SEMPRE deve ter uma resposta (ou argumento) consistente, ou seja, mostrar que entende e está no controle da situação.

Minha lista de posts

Posts Relacionados:

Melhores Posts – Retrospectiva 2010

Leia você também algum dos posts com maior número de acessos do blog Gerenciamento Estratégico de Projetos:

@gerestrategico

Relatório de Progresso

Um interessante instrumento de comunicação com os stakeholders do projeto, e em especial, com o(s) patrocinador(es), é o relatório de progresso.

Um dos resultados alcançados com este reporte regular e adequado às expectativas das partes interessadas é a criação de uma relação de confiança, onde os stakeholders conseguem observar a evolução do projeto e, principalmente, avaliar seu status.

O tipo de informação a ser apresentado e a sua formatação são bastante influenciadas pelo nível hierárquico e/ou nível de decisão do stakeholder e do seu envolvimento no dia a dia do projeto.

Por exemplo, um relatório de progresso enviado ao corpo técnico do projeto não precisa, necessariamente, apresentar o acompanhamento do cronograma financeiro do projeto. Da mesma maneira que este relatório, quando apresentado ao corpo gerencial da organização, não precisa (ou nem mesmo deve) conter detalhes técnicos da implementação e descrições detalhadas de uma dada atividade.

Então, qual a maneira adequada a ser utilizada?

Tenho trabalhado em diferentes projetos, com diferentes stakeholders que demandam diferentes níveis de informação ou detalhamento. Abaixo, uma lista dos tipos de relatório de progresso utilizados:

  • Exemplo 1: preparado e distribuído no corpo do e-mail.
  • Exemplo 2: preparado em documento word, enviado na forma digital e formalmente assinado.
  • Exemplo 3: preparado na forma de apresentação (powerpoint), armazenado no repositório de projeto e o link para acesso é distribuído.

Pois bem, as três formas, desde que em comum acordo, estão adequadas. Claro que, independente da forma, a informação apresentada é que tem o maior peso na escolha.

Agora, a decisão sobre qual forma escolher envolve:

  • avaliar a quantidade e o tipo de informação a ser apresentado.
  • verificar a disponibilidade e o acesso ao repositório de documentos do projeto.
  • analisar a necessidade de formalização (aceite).

Nos exemplos anteriores, a escolha foi feita com base em:

  • Exemplo 1: Escolhido devido a baixa complexidade do projeto, onde a quantidade de informações a serem inseridas era mais reduzida e o projeto tinha curta duração.
  • Exemplo 2: Devido às demandas impostas pelo cliente (e por contrato), o relatório de progresso (que precisava ser formalmente aceito) era avaliado e assinado. Além da assinatura, vários itens gráficos precisavam ser inseridos para facilitar a interpretação das informações e a rápida identificação do status do andamento do projeto.
  • Exemplo 3: Projetos de maior complexidade tem seu reporte facilitado com o uso dessa ferramenta já que fazê-lo no corpo de um e-mail deixaria o texto extremamente longo o que poderia prejudicar a leitura e identificação de pontos de atenção por parte dos stakeholders. Além disso, uma ferramenta adequada permite uma riqueza gráfica que, muitas vezes, torna a leitura mais agradável.

Para deixar mais clara a dificuldade em definir um formato único para o relatório de progresso, vou comentar um feedback interessante que recebi de um gerente (de um nível hierárquico mais elevado na organização) sobre o reporte que eu enviava aos stakeholders (dentre eles o cliente e este mesmo gerente). A avaliação dele foi mais ou menos assim: “… ótimo reporte, bastante completo e bastante extenso também…”. Entendi como um feedback bom, já que o comentário deixou claro que sua percepção era de que eu tinha o projeto sob controle, mas ao mesmo tempo, que havia muita informação para ser analisada.

Então, fiquei analisando este feedback e me indagando como seria possível construir um relacionamento de confiança com o cliente, mantê-lo informado sobre o progresso e, principalmente, sobre os riscos e/ou problemas encontrados, com o mínimo de informação?

Assim, minha interpretação é a de que cada projeto e cada stakeholder vai demandar diferentes níveis de detalhamento e até mesmo de ‘quantidade’ de informação. Assim, cabe ao gerente do projeto analisar as solicitações, dimensionar o esforço necessário e preparar a informação.

Giovani Faria

Meus posts

Controle de Projetos – Dirigir ou Delegar

Uma situação bastante comum é a do gerenciamento de projetos simultâneos (portfolio). Neste sentido, as palavras eficiência, foco, gestão do tempo, entre outras, tornam-se cada vez mais necessárias. Entretanto, é importante ter em mente que todos os projetos são importantes para a organização e para os clientes, e portanto, requerem atenção.

Com este cenário em mente, vamos analisar algumas das possíveis (ou prováveis) posturas do gerente desses projetos para atender às demandas específicas de cada um deles mantendo o controle da situação.

  • Controlar: aqui, o gerente assume controle direto pelo andamento das diferentes atividades através do seu monitoramento constante (especialmente no milestones definidos). Todavia, este posicionamento pode tornar-se inviável considerando o nível de detalhamento requerido pelas atividades e, especialmente, a maturidade da equipe de projeto.
  • Delegar: nesta situação o gerente, embora continue sendo o responsável pelo projeto, delega o monitoramento de algumas atividades para algum dos membros da(s) equipe(s). Este posicionamento é bastante interessante, mas requer do gestor atenção para garantir que este suporte saiba monitorar e reportar tudo que é necessário. Uma ação neste sentido é garantir um bom alinhamento de necessidades e expectativas entre as partes (o gerente e seu suporte).

Planilhas de acompanhamento, post its, gadgets, kanban (to do, ongoing, done), enfim, ferramentas de gestão em geral (waterfall, agile, etc.), podem ajudar bastante nesse controle. Entretanto, é preciso garantir que estas ferramentas sejam atualizadas correta e constantemente para refletirem a realidade dos projetos.

Giovani Faria

Meus posts

Milestones

Um importante item a ser definido no planejamento dos projetos refere-se aos Milestones. Na definição do PMBoK a identificação dos milestones é uma das atividades do grupo de processo de planejamento que preve a criação da lista de milestones, que, por sua vez, fará parte do Project Charter.

Muitas vezes, os milestones são associados às mudanças de fase de projeto. Entretanto, é preciso entendê-los para que estes pontos de avaliação/verificação sejam realmente úteis para o projeto.

  • No PMBoK: “um milestone é um momento significativo ou evento no projeto. A lista milestones identifica todos os milestones e indica quais são obrigatórios, tais como aqueles necessários por contrato; ou opcionais, como os baseados nas informações históricas”.
  • O CMMi (Capability Maturity Model Integration), no seu modelo de melhoria de processo aplicado aos projetos de desenvolvimento, estabelece algumas práticas (Specific Practices) que visam a identificação dos milestones (que são associados com a garantia de finalização de determinadas entregas) e também a sua revisão (onde o objetivo é avaliar a produção realizada e os resultados do projeto nos milestones selecionados).

Os milestones, ou pontos de decisão, também recebem outros nomes, tais como: phase exits, phase gates, decision gates, stage gates, kill points.

O estabelecimento dos milestones pode ser baseado:

  • em eventos: como os finais de fase, por exemplo.
  • no calendário: por exemplo, o final dos sprints (Agile) da fase de desenvolvimento, já que sua data deve ser definida.
  • no orçamento: onde a avaliação do andamento é feita em momentos onde determinados percentuais do orçamento do projeto já foram consumidos (por exemplo, a cada 10% do budget total investido).

Os finais de fase são, naturalmente, pontos de reavaliação do andamento. Entretanto, não podem ser únicos, especialmente considerando-se que os resultados de uma fase são fatores de decisão sobre a continuidade (ou não) da próxima fase; já que o objetivo é atuar no projeto conforme a situação atual, e não simplesmente listar o status do mesmo. Ou seja, de nada adianta chegar a um dado momento do projeto pra ter certeza de que algo saiu errado, é preciso antecipar-se e atuar preventivamente.

Algumas práticas interessantes (e necessárias) compreendem:

  • a identificação dos milestones no cronograma do projeto (por exemplo, nos diagramas de sequenciamento de atividades.
  • envolvimento dos stakeholders relevantes (gerência, equipe, cliente, usuários finais, fornecedores, etc.)

Durante a avaliação do projeto nos milestones, várias análises podem ser feitas. Dentre elas:

Como resultado dessa análise deve-se ter a revisão e atualização do plano de projeto (compromissos firmados, escopo, riscos, planos de ação,etc).

Em resumo, o milestone deve ser entendido como um momento do projeto onde será feita uma avaliação detalhada de seu andamento e a determinação dos próximos passos a serem seguidos. Neste sentido, é importante que os milestones sejam estabelecidos em momentos onde seja possível ao gerente do projeto, juntamente com sua equipe, tomar ações que possam garantir que o projeto seja concluído com êxito.

Giovani Faria

Meus posts

Provocações #2: Foco sempre nos objetivos

Tenha sempre os olhos nos objetivos do seu projeto.
A perda do foco acarreta perda de controle, perda de esforço, retrabalho e principalmente surpresas desagradáveis no fim do projeto.

O Gerente Emocional

O que faz de um Gerente de Projetos um bom gerente?

Pense em um GP com quem você já tenha trabalhado e que seja uma referência pra você. Quais são as características intrínsecas dele (ou dela) que o diferenciam dos demais profissionais com quem você já teve contato? É bem provável que sua resposta seja alguma característica comportamental e não técnica dessa pessoa…

Essas características comportamentais são relacionadas à Inteligência Emocional, conceito popularizado pelo jornalista e psicólogo americano Daniel Goleman que envolve habilidades para perceber, entender e influenciar as próprias emoções, as de outras pessoas, ou até mesmo de um grupo, tornando-as coadjuvantes no processo de crescimento interno. Segundo ele, a inteligência emocional é a maior responsável pelo sucesso ou insucesso dos indivíduos.

A Inteligência Emocional é composta por cinco habilidades, que se complementam:

  • Auto-Conhecimento Emocional
    Líderes com auto-conhecimento desenvolvido sabem identificar corretamente suas emoções, forças, fraquezas e habilidades, e reconhecer seu impacto na tomada de decisões.
  • Auto-Controle
    Habilidade de lidar com os próprios sentimentos, emoções e impulsos, adequando-os a cada situação vivida. Um GP com auto-controle é capaz de resolver conflitos agindo com integridade frente a impulsos e comportamentos desordenados de superiores, colegas e subordinados, transformando emoções em repostas ponderadas sobre a melhor decisão a ser tomada.
  • Auto-Motivação
    Capacidade de dirigir as emoções a serviço de um objetivo ou realização pessoal. Líderes auto-motivados perseguem objetivos e são comprometidos com metas, transformando dificuldades em oportunidades e dando um significado maior ao trabalho sendo feito. A motivação, nesse caso, vai muito além das recompensas financeiras.
  • Empatia
    Habilidade de sentir, entender e reagir às emoções de outros em relacionamentos sociais, reconhecer as emoções de outras pessoas e “se colocar no lugar” dos outros. Empatia é compreender as emoções relacionadas às diferentes culturas, modos de ser, formação profissional, talentos e motivações que serão reforçadas ou confirmadas
  • Habilidade Social
    Habilidade de inspirar, influenciar e desenvolver outras pessoas em situações de resolução de conflitos. É saber “equilibrar todos os pratos” e manter o projeto rodando

Enquanto as três primeiras são intrapessoais (afetam a relação do indivíduo consigo mesmo) as duas últimas tem caráter interpessoal, afetando a relação entre  Gerente de Projetos e stakeholders. Uma vez que gerenciar projetos tem a ver com fazer coisas através de pessoas fica fácil perceber quão importantes são as habilidades em lidar com pessoas. No entanto, vale ressaltar que não existe nenhuma receita infalível de como liderar, tampouco o melhor estilo de liderança. Diante de diferentes circunstâncias o gerente deve identificar a melhor maneira de se relacionar com as pessoas.

Para saber mais: o blog Papo GP tem uma sessão inteira dedicada ao assunto, inclusive discorrendo sobre as teoria motivacionais. Vale a visita.

Um abraço,

Eamon Sousa

Como ser um grande gerente

Ler livros sobre gerenciamento normalmente são um porre, principalmente quando se procura algo que não seja teoria pura e sim o “pulo do gato”. Nesse meio o pulo do gato vale mais do que o próprio gato!

Outro dia me deparei com um desses, fato raro e valeu algumas anotações que gostaria de compartilhar com os amigos do blog.

Gostei do livro porque ele não é um livro de administração clássico: com teoria e com regras de como se deve fazer ou não… Ao contrário, ele narra o cotidiano de um gerente de projetos que tem o perfil que todos gostariam de ter sendo gerentes de projetos. Nele, me lembro que são expostos detalhes que separam evidentemente um idiota e um gerente funcional sem apontar o dedo pro idiota, nem lançar pétalas de rosa no caminho dos funcionais.

Não vou explicar o que cada um dos segredos trás na sua semiótica, a interpretação deixo a critério das sinapses de cada um.

Primeiro Segredo

Grandes gerentes trabalham primeiramente com o contato direto, e em particular, atrás da cortina do palco, nos bastidores. Não é o artista principal, mas cria maneiras para que os artistas principais o sejam.

Grandes Gerentes

  • Desenvolvem as relações interpessoais de seu grupo;
  • Criam um ambiente de trabalho propício para a realização do projeto;
  • Constroem a confiança.

Desenvolvimento de Relações Interpessoais

  • Aprenda que seu time é formado por seres humanos;
  • Forneça feedback efetivo;
  • Auxilie na melhora da performance;
  • Delegue a capacidade de construir ao time.

Criação de um Ambiente de Trabalho

  • Gerencie seu portfólio de projetos;
  • Conheça sua missão, visão e reconhece seus valores;
  • Capitalize estrategicamente os trabalhos importantes;
  • Saiba quando e como dizer “não”.

Foco nas Mudanças e Feedback

  • Crie situações de feedbacks espontâneos;
  • Descreva o ambiente ou resultados de maneira que todos possam ouvir;
  • Use a primeira pessoa do singular para ações não somente relacionadas as conquistas;
  • Incentive mudanças que impactem de maneira positiva ao grupo e gerem benefícios ao projeto;

Trabalhe pensando na organização

  • Use das negociações para realizar o trabalho da melhor maneira possível dentro da organização;
  • Trabalhe junto com outros gerentes;
  • Não crie rivais e sim parceiros.

Use a melhor ferramenta de gestão de projetos

  • Comunique de forma clara e objetiva;
  • Faça acordos sobre objetivos e expectativas.

Reunião como ferramenta produtiva

  • Incentive a presença dos membros do seu time;
  • Informe sobre os acontecimentos relacionados ao projeto;
  • Seja informado do status das atividades em andamento;
  • Pergunte sobre os obstáculos;
  • Questione sobre necessidade de ajuda;
  • Pense no desenvolvimento da carreira dos membros do projeto;
  • Incentive outros tópicos que o time deseje compartilhar;
  • Revise as ações tomadas e as que deverão ser tomadas;
  • Agradeça a presença dos membros do seu time;

Aprenda sobre você mesmo

  • O que me trouxe até aqui?
  • O que preciso para me manter aqui?
  • E o meu feedback?

Crie confiança

  • Aplique as práticas gerenciais consistentemente;
  • Incentive a criatividade;
  • Elogie iniciativas do novo, mesmo que as mesmas não sejam satisfatoriamente um sucesso;
  • Alerte sobre erros reincidentes.

Devem estar pensando, qual o nome desse livro?? Livros bons pra mim marcam pelo conteúdo, não pelo nome da capa!

Saudações, Marcelo

Avaliação de Desempenho de Projetos – Por que, Quando e Como Fazer

Não é novidade que um importante item no gerenciamento de projetos refere-se a avaliação de desempenho ou do andamento do projeto. Neste sentido, além de avaliar a situação atual do projeto é preciso também verificar se as tendências apontam para um bom resultado.

A função principal do Gerente de Projetos é garantir que os objetivos do projeto sejam atingidos. Para isso, algumas restrições importantes são estabelecidas. Entre elas temos a chamada Triple Constraint, que envolve Custo, Escopo e Tempo (prazo).

Com isso em mente, e também pensando que a busca da eficiência na gestão de projetos passa, necessariamente, por um amadurecimento nos sistemas e metodologias de controle utilizados, vamos apresentar maneiras de avaliar a performance de projetos respondendo a algumas questões:

POR QUE medir?

A avaliação quantitativa do andamento do projeto é ferramenta indispensável na sua gestão. Não basta ter o feeling (qualitativo) de que o projeto está (ou não) sob controle; é necessário também ter medidas objetivas de sua performance.

QUEM  envolver?

  • Equipe: É importante ter o envolvimento da equipe de desenvolvimento uma vez que serve como meio de se obter seu comprometimento na execução do trabalho.
  • Cliente: A participação do cliente fortalece a relação de parceria no planejamento e busca de soluções.
  • Organização: O envolvimento do patrocinador/equipe gerencial/PMO da empresa permite obter o compromisso no suporte e fornecimento dos recursos necessários, além de garantir o alinhamento dos objetivos do projeto com os objetivos organizacionais.

O QUE medir?

  • Tempo (prazo): Item básico em qualquer projeto é a data de entrega que deve ser estabelecida e concordada com os stakeholders principais do projeto.
  • Custo: Tão importante quanto não exceder o custo é também não superestimá-lo. Se por um lado uma estimativa de custo muito maior do que o necessário pode trazer maior lucratividade, por outro, pode acabar por causar desconforto junto ao cliente/sponsor e também influenciar no take rate das propostas apresentadas pela empresa. Isto é, quanto mais precisa a determinação dos custos do projeto, melhor será a atuação do departamento comercial na negociação de contratos.
  • Escopo: A definição clara de todos (e somente estes) os itens para entrega delimita o trabalho do projeto e fixa a expectativa do cliente.
  • Satisfação do Cliente: Quanto mais próximo do projeto estiver o cliente, maiores a chances de sucesso do projeto. Assim, é importante discutir uma maneira eficiente de envolvê-lo no projeto e de avaliar este envolvimento e verificar o atendimento de suas expectativas.

QUANDO medir?

Durante o planejamento do projeto é importante ter definidos os milestones (marcos / pontos de decisão) importantes do projeto. Neste momento, os indicadores do projeto devem ser avaliados de modo a proporcionar informações suficientes para a tomada de decisões na definição das ações (corretivas) necessárias. Algumas conclusões possíveis dessa avaliação podem determinar tanto o cancelamento do projeto como o levantamento de novas necessidades de recursos (humanos, financeiros, infra-estrutura, etc.) para a continuidade do mesmo.

Esses marcos podem ser estabelecidos em função:

  • do tamanho (volume de horas) do projeto: milestones ocorrendo  a cada % de horas executadas. – Interessante para projetos de duração média (por exemplo, 5.000 h), onde uma avaliação a cada 20% de trabalho executado pode ser suficiente.
  • orçamento (budget) disponível: milestones ocorrendo a cada % de budget gasto. – Adequado em projetos de curta duração e que envolvem, além da alocação de recursos humanos, de investimentos/custos por exemplo, de infra-estrutura.
  • calendário: milestones ocorrendo a cada período definido (dias/meses). – Este tipo de definição é mais coerente com projetos de longa duração.

Esta definição do número de pontos de avaliação (marcos) deve ser suficiente para proporcionar as informações necessárias à tomada de decisão. Ou seja, a equipe de gerenciamento de projeto deve ter condições de tomar ações, por exemplo, de modo a corrigir uma tendência negativa no andamento do projeto.

COMO Fazer?

O PMI, por exemplo, no próprio PMBoK traz alguns índices de performance utilizados (além disso, consulte Earned Value Managment):

  • CPI: Índice de Performance de Custo. Permite identificar a performance referente aos custos do projeto. CPI = Earned Value / Actual Cost
  • SPI: Índice de Performance de Prazo. Permite verificar se o volume de atividades efetivamente executado está coerente com o planejamento e atende aos prazos estabelecidos. SPI = Earned Value / Planned Value

Além de algumas estimativas para avaliação de tendência:

  1. EAC: Estimativa ao Final do Projeto. Avalia qual será o custo final do projeto com a manutenção da tendência de progresso.
  2. ETC: Estimativa para Completar o Projeto. Avalia qual o custo para realizar as atividades restantes do projeto.

Já no SCRUM as ferramentas para avaliação são:

  • Burndown: equivalente ao SPI, permite a avaliação do andamento da execução das atividades planejadas (sprint backlog). Exemplos.
  • Product/Sprint backlog list: Útil no tracking de todos os entregáveis do projeto. No Product backlog temos listados os requisitos e no Sprint Backlog seu detalhamento em atividades menores que compoem cada um dos requisitos.
  • Sprint Review: Avaliação do resultado do projeto, com a participação do cliente, onde pode-se verificar se suas expectativas foram atendidas.

Giovani Faria

Meus posts

Como adquirir experiência em Gerenciamento de Projetos

Depois que publiquei o post “Quero ser Gerente de Projetos”, acabei recebendo alguns novos contatos de pessoas que acessaram o conteúdo. Nestes contatos acabei sendo indagado de diferentes formas sobre o assunto que me levaram a uma nova reflexão sobre a matéria. Assim, para complementar o assunto, vou iniciar apresentando um pequeno diálogo (que é atribuído a um autor desconhecido) entre o mestre e seu discípulo:

  • Mestre, como faço para me tornar um sábio?
  • Boas escolhas – responde o mestre.
  • Mas como fazer boas escolhas?
  • Experiência – diz o mestre.
  • E como adquirir experiência, mestre?
  • Más escolhas.

Analisando este diálogo sob o ponto de vista da construção de uma carreira em Gerenciamento de Projetos entendo que, embora, perfil (vocação) e competência técnica sejam fatores de extrema importância, a vivência (“boas e más escolhas”) é um dos grandes fatores de diferenciação do profissional. E como bem disse o mestre ao seu discípulo, para se aprender a fazer boas escolhas podemos acabar fazendo más escolhas. Ou seja, estamos constante aprendendo com nossos erros. A capacitação por meio de treinamentos nos ajuda a entender O Que e Por Que fazer uma série de atividades em termos das melhores práticas, mas, não consegue nos dizer exatamente Como fazer (que é um dos fatores que sofre forte influência das características da operação e estrutura da empresa e de seu segmento de atuação).

Entretanto, mesmo este parecendo ser o caminho natural das coisas (‘…erros e acertos…’), não é normalmente a maneira como as empresas gostam (ou precisam) que seja a atuação de seus profissionais, em especial, os de gerenciamento de projetos. A forte concorrência e dinamismo do mercado estabelece demandas muito mais agressivas para as empresas, onde as falhas no trabalho de seus profissionais acabam por não ser normalmente toleradas. Neste cenário, como formar um profissional em gerenciamento de projetos se o que ele precisa é de experiência, mas a dinâmica do trabalho não permite esta liberdade? Uma resposta pode estar no coaching.

Neste coaching o candidato a gerente de projetos (discípulo) deve ter alguém designado para orientá-lo. Esta figura do mestre (coach) pode ser:

  • Um Gerente de Projetos que tem em sua equipe um assistente em gerenciamento de projetos que será treinado
  • Um Gerente de Projetos mais experiente que ficará responsável pelo treinamento/orientação/monitoramento de outro em formação
  • O PMO (Project Management Office), responsável, entre outras coisas, pela capacitação dos profissionais de gerenciamento de projetos

Um opção de leitura sobre o tema é: Coaching: o Exercício da Liderança

Giovani Faria

Meus posts

Outros posts:

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Join 133 other followers