Menu
Esqueceu a senha? Fazer cadastro

Gestão de mudanças, ameaça ou desafio dos GPs?

O processo de transformação das organizações é cada vez mais freqüente. Mudanças acontecem por: influências de agentes internos e externos, evolução tecnológica, melhoria de processos, novos processos, fusões e aquisições, dentre outras. Resulta um mal necessário para as corporações se manterem no mercado. Ou seja, a mudança é algo inevitável.

Outra realidade, totalmente antagônica, é que as pessoas são resistentes as mudanças por natureza. O ser humano é assim.

Se adicionamos, também, neste contexto, que uma das características de qualquer projeto é ser um agente de mudanças, temos a trilogia perfeita para o caos acontecer se não são tomadas as ações correspondentes para evitar esse possível caminho de insucesso na implantação de mudanças nas organizações.

Assim, pode acontecer que o gerente de projetos que realizou o máximo esforço para gerenciar bem as variáveis hard do seu projeto, como escopo, custo, prazo, riscos, utilizando as melhores ferramentas disponíveis, na hora da implantação pode chegar a se perguntar:

Quem colocou essas pessoas no meu caminho? ..

E o pior, não achar as respostas satisfatórias para resolver seu problema.

De novo as pessoas!!” Como falava a minha vovozinha.

Se as pessoas falassem que estão perturbadas, desconfortadas ou incomodadas com a alteração da sua rotina, seria muito mais fácil, o problema é que dificilmente falam!

Como as pessoas manifestam essa desconformidade?

Nos aspectos comportamentais, no relacionamento interpessoal, no estresse, na falta de motivação, de entusiasmo e produtividade. São barreiras como forma de proteção originada pelos medos e pela insegurança.

Infelizmente não temos um guia de como lidar com pessoas resistentes à mudanças, pois cada caso é um caso. O sucesso da gestão de projetos estará nas habilidades soft do perfil do Gerente de Projeto. Habilidades que permitam detectar, atender e resolver os medos, a insegurança, e desenvolver um plano de ações para mitigar os riscos potenciais no momento da implantação do seu projeto.

O PM.Survey.org é uma pesquisa anual organizada voluntariamente por chapters do PMI, e conta com a participação de  centenas de organizações de diferentes países.

Na última pesquisa publicada em 2011, registraram os seguintes resultados:

 

  • Principais habilidades necessárias e valorizadas ao gerenciar projetos nas organizações:

 

  • Principais deficiências dos Gerentes de Projetos nas organizações:

 

  • Problemas mais frequentes em Projetos:

 

 

entre as mais importantes.

 

Vemos claramente que os problemas de habilidades soft lideram a origem da maioria dos problemas nas organizações participantes da pesquisa.

 

  • Aspectos considerados na metodologia de Gerenciamento de Projetos:

 

 

 

Ou seja, a comunicação, os recursos humanos e a integração não estão entre os principais aspectos considerados na metodologia de Gerenciamento de Projetos.

Isso demonstra que as organizações não estão dando o devido valor ao fator humano e as conseqüências estão registradas claramente nos resultados obtidos nas mesmas estatísticas.

O gerente de projetos, cada vez mais, está obrigado a realizar a gestão das pessoas para a implantação das mudanças dos seus projetos e atingir o sucesso esperado.

“Vivemos um momento da história humana, onde o que muda é a velocidade com que as mudanças estão acontecendo” (Gonçalves, 2012).

Como será possível enfrentar e vencer este antagonismo nas organizações?

A minha sugestão é pensar nas pessoas desde o início do projeto. Uma boa notícia é que o Guia PMBOK 5º Edição, inclui no capítulo 13 a gestão de stakeholders.

O planejamento inicial deve começar pela análise dos valores e benefícios que o projeto aportará, de um estudo exaustivo dos stakeholders e seus interesses, e, principalmente, do mapeamento do impacto dos primeiros nas expectativas dos segundos. Toda a estratégia da gestão integrada deve estar considerada no plano de comunicação do projeto e em um plano adicional sobre gestão de mudança.

Caberá ao Gerente de Projetos desenvolver as habilidades necessárias para obter as informações que precisa.

Recentemente li o livro “Gestão de Mudanças” de Vicente Gonçalves e Carla Campos e gostei muito. Explica uma metodologia a seguir pelos gerentes de projetos para ajudar no sucesso dos projetos. Recomendo sua leitura.

 

“Planejazendo”

Por: Paulo Camargo.
Nas empresas de tecnologia em que trabalhei durante aproximadamente 10 anos da minha carreira, desde fornecedoras de equipamentos até prestadoras de serviços de Telecom, raros foram os momentos em que paramos como equipe para realmente planejar um projeto ou programa do início ao fim. Isto é, fazer um planejamento completo antes de iniciar a execução do projeto.

 

Na verdade, consigo contar em alguns dedos quantas vezes isso aconteceu: uma vez para ser bem exato.
Quando falo em planejar, não me refiro a fazer simplesmente um cronograma de entregas ou definição do escopo – isso era feito na maioria das vezes. Refiro-me à criação e atualização de um business case completo e bem feito, elaboração de fluxo de caixa e definição de benefícios, além da preparação de uma linha de base de performance para permitir a Análise de Valor Agregado ao longo dos projetos.
Tudo sempre foi para ontem, sempre “planejazendo”, sem se saber quanto o projeto iria custar. Ou seja, estávamos sempre planejando e executando. Não necessariamente estávamos executando o que planejávamos. No final do projeto, às vezes era difícil saber se havia sido realizado dentro do planejado.

 

Na prática, a situação era que haviam orçamentos definidos e precisávamos “encaixar” o projeto dentro das restrições de tempo. Como os orçamentos eram bastante rígidos, era natural termos diversas mudanças de escopo para realizar aquilo que era possível dentro da restrição tempo-custo.

 

Para minha surpresa, em projetos maiores que participei no Brasil, envolvendo contratos tipo EPCs, (Engineering, Procurement and Construction) a situação não foi  muito diferente. Sofremos bastante com o “planejazendo”.
O que percebo é que quanto maior o projeto (orçamento) existe mais espaço para “adequação de escopo e orçamento” e, portanto, maior flexibilidade nesses quesitos.
Atualmente, tenho tido experiências bastante diferentes. Em um dos projetos que gerencio no Canadá, estamos na fase de refinamento do Business Case e Planejamento. Diferente de todos os outros projetos que já participei, essa fase tem duração de 14 meses e um orçamento considerável de perto de uma dezena de milhões de dólares. Estou adorando ter esse tempo todo para chegar a um ponto de decisão  com um Business Case muito bem elaborado, analisando todos os riscos para o negócio e para o programa em si.
Seria ótimo se eu tivesse essa fase (claro que em menores proporções) em todos os projetos que gerenciei.
E você, tem tempo para planejar ou está sempre “planejazendo”?

 

 

Identificando Projetos Problemáticos

É bastante provável que o amigo leitor já tenha participado de projetos problemáticos (desfiadores?) ou mesmo fracassados. Ao menos, todos nós já ouvimos falar de algum projeto desse tipo… Infelizmente, uma das maiores dificuldades em consolidar boas lições aprendidas é que existe uma propensão humana em minimizar os fracassos e exaltar os sucessos.

Óbvio, ninguém quer fazer parte de um projeto fracassado. Muito menos sair por aí falando que está em um projeto desses. É mais fácil nos gabarmos de ser parte de um mega projeto bem sucedido, certo? Como resultado, a identificação de projetos problemáticos é difícil porque os sintomas nem sempre saltam aos olhos.

Isto é, um projeto problemático caminha para o fracasso a passos lentos. Não é da noite para o dia. Além disso, esses sinais vão sendo mascarados porque naturalmente existem stakeholders tentando proteger o projeto. Quando se percebe que o projeto fracassou já é tarde, a maioria dos interessados já abandonou o barco.

Eis alguns sintomas de projetos problemáticos:

  • Stakeholders
    • Insatisfação por parte dos clientes (internos ou externos)
    • Falta de envolvimento dos clientes
    • Falta de apoio e / ou insatisfação do patrocinador / gerência sênior
  • Recursos
    • Corte de recursos financeiros ou insuficiência
    • Turnover da equipe
    • Moral reduzida e aumento nos conflitos dentro da equipe
    • Falta de capacidade técnica
    • Recursos materiais reduzidos ou indisponíveis
  • Escopo
    • Mudanças significativas e / ou frequentes
    • Falta de alinhamento / acordo
    • Documentação insuficiente ou inadequada
    • Processos de controle ineficientes
    • Aumento da informalidade
  • Cronograma
    • Desvios significativos
    • Violação de marcos importantes
    • Metas contratuais
  • Custos
    • Desvios significativos
    • Fluxo de caixa do projeto
  • Riscos
    • Aumento da exposição ao risco e novos riscos
    • Plano de respostas aos riscos ineficiente

 

Esses e outros sintomas são pouco evidentes até que se tornem críticos. Agora vamos imaginar que, como gerente de projetos, você herdou um projeto problemático.

A situação é a seguinte: o gerente do projeto anterior abandonou a empresa e a equipe perdeu 25% dos seus membros, dentre eles dois eram críticos para o sucesso do projeto. Além disso, a gerência sênior e o cliente estão profundamente insatisfeitos com o atraso nas entregas (8 meses de atraso) e o aumento nos custos (30% do orçamento total). Considerando que se trata de um grande projeto de construção, os problemas estão afetando a comunidade local e as autoridades governamentais estão questionando a execução da obra.

 

Sua missão, como novo GP do projeto é o recuperar. O que você faz?

a)      Senta e chora.

b)      Enrola o quanto puder, enquanto procura outro emprego…

c)      Diz que é impossível e recusa o projeto.

d)      Aceita o desafio e vê o que dá para fazer…

Não é fácil. Quando lanço essa pergunta (sem dar alternativas), a grande maioria das pessoas responde algo parecido com d). Afinal, manda quem pode, obedece quem tem juízo. Se você foi designado GP, não há como dizer que o projeto é impossível. Aliás, só é impossível se você parar para pensar…

Entretanto, o fato é que nem todo projeto deve ser salvo. Eu diria que grande parte dos projetos problemáticos deve ser sacrificado. A primeira coisa a se fazer é reunir informações exatamente para decidir se o projeto deve continuar ou não. Será que a justificativa de negócio e os benefícios desejados / prometidos ainda podem ser entregues a um custo de oportunidade razoável?

Todavia, os famosos sunk costs e o orgulho pessoal são incompatíveis. É duro dizer que o meu projeto fracassou e precisa ser encerrado, não é? Ficamos pensando nos R$500mil que já foram gastos, 10 meses de trabalho da equipe e todo um esforço para nada. Acabamos, então, dando um jeitinho de continuar o projeto e afundar mais outros R$400mil, 7 meses e não chegar a resultado algum…

Portanto, vale mais a pena prevenir do que remedir, como diz o velho ditado. Um projeto bem documentado, realista e realizável, que tenha suporte e apoio das partes interessadas evita os sintomas que levam ao fracasso dos projetos.

 

Nos próximos posts, veremos algumas técnicas e métodos para recuperar projetos problemáticos. O primeiro passo, como vimos, é decidir se queremos continuar o projeto ou não (faz sentido continuar?). Em segundo lugar, obviamente não será possível transformar um fracasso em um sucesso, é preciso avaliar os tradeoffs (custo-benefício) e redefinir qual será a nova diretriz (escopo-tempo-custo atrelados a um business case). Até lá!

 

PMO de sucesso precisa ter foco!

Uma proposta de modelo para Escritórios de Projetos

 

Caro amigo leitor, que tal se pudéssemos criar um modelo de negócios para os nossos escritórios de projetos? Certamente, seria algo bastante útil, pois uma modelo de negócios nos permite ter foco. Ele deve descrever como criamos valor, capturamos o valor criado e distribuímos esse valor. Simples, direto e extremamente útil.

Figura 1 – Business Model Toolbox

 Vimos em posts anteriores (PMO Model Generation , Um PMO para Chamar de Seu) um pouco sobre Business Model Generation. Agora iremos detalhar como seria um possível modelo de negócios para um escritório de projetos genérico. Para isso, necessitamos definir e detalhar os componentes do nosso modelo de negócios:

Proposta de Valor

  • O que o PMO faz para criar valor para os clientes?
  • Quais produtos e serviços devem ser oferecidos pelo PMO?
  • Como esses produtos e serviços serão oferecidos?
  • Quais os diferenciais do PMO?

Segmentos de Clientes

  • Quem são os clientes dos serviços prestados pelo PMO?
  • O que é importante para esses clientes?
  • Quais suas necessidades e preferências?
  • Como agrupá-los / segmenta-los?

Canais

  • Como os segmentos de clientes poderão usufruir dos produtos e serviços do PMO?

Relacionamento

  • Como o PMO poderá se comunicar com seus clientes e vice-versa

Fontes de Receita

  • Quais seriam as potenciais fontes de renda do PMO?
  • Quais são os indicadores de sucesso do PMO?
  • Como esses indicadores estão relacionados com a satisfação dos segmentos de clientes e com o uso dos produtos e serviços disponibilizados pelo PMO?

Parcerias

  • Quais pessoas, grupos ou entidades podem ajudar o PMO a criar, capturar e distribuir valor?
  • Quais parcerias internas e externas à organização podem ajudar o PMO em suas atividades-chave e / ou oferecendo recursos principais?

Atividades-Chave

  • Quais processos, procedimentos e atividades devem ser desempenhados dentro do PMO para que ele materialize sua Proposta de Valor e a entregue aos Segmentos de Clientes?

Recursos Principais

  • Quais recursos (pessoas, equipamentos, infraestrutura, dinheiro) são necessários para o funcionamento do PMO e a realização de suas atividades?

Estrutura de Custos

  • Qual é a estrutura de custos de funcionamento do PMO, considerando suas atividades, recursos necessários e parcerias?
  • Quais indicadores de custos podem ser utilizados?

A primeira coisa, antes de delinear a missão do PMO, é definir seu nível hierárquico na organização. De acordo com Crawford (2001), temos:

PMO Corporativo ou Estratégico

  • De modo geral, o objetivo principal deste tipo de PMO é criar diretrizes e políticas para o gerenciamento de projetos dentro da organização, podendo incluir ou não o gerenciamento do portfólio de projetos estratégicos.

PMO Departamental

  • PMOs departamentais ou setoriais podem estar em diferentes níveis da organização, frequentemente estão no âmbito tático. São escritórios de projetos que desdobram as diretrizes e objetivos estratégicos em programas e projetos. Eles podem incluir o gerenciamento de programas, compartilhamentos de recursos e treinamentos, entre outras funções.

PMO de Suporte

  • Trata-se de um escritório que oferece suporte a um único projeto ou programa, geralmente projetos vultosos ou mega-projetos. Seu objetivo principal é auxiliar o gerente do projeto e sua equipe de planejamento e controle nas atividades administrativas e de suporte.

Uma vez identificado o nível, a missão do PMO fica mais clara, assim como seus stakeholders e segmentos de clientes. Porém, para que seja possível desenhar um bom modelo de negócios para o PMO, é necessário determinar quais serão as suas funções, que poderiam estar entre os dois extremos:

PMO como mero “observador”

  • Funciona como uma “estação meteorológica”, simplesmente coletando informações do ambiente
  • Obtém informações dos projetos e as consolida para os níveis superiores, não possui autoridade sobre os projetos
  • Geralmente, não oferece serviços de suporte aos projeto, funcionando mais como um “secretário” a gerência sênior

PMO como autoridade máxima em projetos

  • Define políticas, documentação e metodologia
  • Gerencia recursos, incluindo infraestrutura e treinamentos
  • Seleciona, prioriza e autoriza projetos
  • Designa gerentes de projetos e equipes

Suponha que desejamos um PMO Estratégico com autoridade máxima sobre os projetos. A partir dessa definição, podemos criar a Proposta de Valor do nosso modelo de negócios.

Proposta de Valor: O PMO Estratégico será responsável por selecionar, priorizar e autorizar projetos estratégicos, coordenando recursos junto às áreas funcionais e fornecedores, negociando com clientes internos e externos dos projetos, além de centralizar informações para a gerência sênior.

Essa proposta de valor nos permite identificar nossos Segmentos de Clientes, bem como detalhar quais serão os produtos oferecidos e serviços prestados pelo PMO que criem valor para os clientes. Para isso, podemos visitar o PMO Maturity Cube, por exemplo, e elencar alguns serviços comumente realizados pelos escritórios de projetos (As 27 funções de Hobbs e Aubry – www.pmomaturitycube.org):

1. Informar o status dos projetos para a alta gerência

2. Desenvolver e implementar a metodologia padrão

3. Monitorar e controlar o desempenho de projetos

4. Desenvolver as competências dos profissionais, incluindo treinamento

5. Implementar e operar sistemas de informação dos projetos

6. Prover aconselhamento à alta gerência

7. Coordenar e integrar projetos de um portfólio

8. Desenvolver e manter um quadro estratégico de projetos (project scoreboard)

9. Promover o gerenciamento de projetos dentro da organização

10. Monitorar e controlar o desempenho do próprio PMO

11. Participar do planejamento estratégico

12. Prover mentoring para os Gerentes de Projetos

13. Gerenciar um ou mais portfólios

14. Identificar, selecionar e priorizar novos projetos

15. Gerenciar arquivos/acervos de documentação de projetos

16. Gerenciar um ou mais programas

17. Conduzir auditorias de projetos

18. Gerenciar interfaces de clientes

19. Prover um conjunto de ferramentas sem o esforço de padronização

20. Executar tarefas especializadas para os Gerentes de Projetos

21. Alocar recursos

23. Implementar e gerenciar banco de dados de lições aprendidas

24. Implementar e gerenciar banco de dados de riscos

25. Gerenciar os benefícios de programas

26. Mapear o relacionamento e o ambiente de projetos

27. Recrutar, selecionar, avaliar e determinar salários dos Gerentes de Projetos

Segmentos de Clientes (identificando serviços desejados / valor):

Gerentes funcionais

  • Uso dos recursos de modo a não impactar operações
  • Compartilhar informações
  • Sistema centralizado de planejamento e disponibilidade de recursos

Gerentes de projetos

  • PMO oferecerá suporte, mentoring e coaching
  • Planejamento, histórico, lições aprendidas e documentação
  • Treinamentos, infraestrutura

Membros de equipes de projetos

  • Treinamentos
  • Informações sobre as tarefas

Fornecedores

  • PMO auxiliará na gestão dos contratos
  • Disponibilizará informações aos fornecedores
  • Maior integração

Gerência sênior

  • PMO consolida informações, criando métricas e dashboards
  • Apoio a decisão

Canais:

  • Infraestrutura
  • Presencial
  • Reuniões
  • Treinamentos
  • Coaching / mentoring
  • Suporte administrativo
  • Online
  • Enterprise Project Management
  • Sistema de gestão de contratos
  • Software EPM para gerenciamento de projetos e programas
  • Enterprise Portfolio Management
  • Gestão do Conhecimento
  • Telefone / e-mails
  • Outros serviços disponibilizados pelo PMO

 Relacionamento com Clientes:

  • Feedback
  • Workshops e Seminários
  • Caixa de sugestões online (email)
  • Inteligência para identificar novas necessidades
  • Benchmarking
  • Monitoramento do uso de ferramentas e infraestrutura
  • Delineamento de plano de carreira em gerenciamento de projetos

 Fontes de Receita (ou indicadores de performance do PMO):

  • ROI dos projetos / portfólio
  • Indicadores agregados de performance dos projetos
  • Indicadores de desenvolvimento humano (gerentes e equipes de projetos)

 

Figura 2 – Inserindo detalhes

 Até agora, trabalhamos na parte externa do modelo de negócios. Isto é, definimos claramente nossa proposta de valor, o que fazemos, por que fazemos e como fazemos. O foco está nos clientes, criar valor para eles. Não basta apenas criar valor, é preciso que isso chegue até os clientes (canais) e devemos procurar reforçar o feedback e relacionamento, de maneira a verificar / confirmar se realmente os clientes enxergam valor nos produtos e serviços oferecidos pelo PMO. Finalmente, podemos imaginar fontes de receitas.

Em nosso caso, modelo de negócios de um PMO, que é uma estrutura organizacional interna da empresa, as receitas não são necessariamente financeiras, podemos pensar em indicadores de valor agregado para a organização.

Agora passaremos à parte “interna” do modelo de negócios. Ou seja, o que devemos fazer para realizar / materializar aquilo que prometemos na parte externa (proposta de valor, produtos e serviços, segmentos de clientes, relacionamento e canais). Iremos nos concentrar em quais são os recursos essenciais e quais são as atividades que precisam ser desempenhadas.

Nem todas as atividades e recursos precisam pertencer ao PMO ou ser realizadas por ele. Pode ser interessante celebrar parcerias estratégicas que desempenhem ou ajudem a desempenhar as funções do PMO. Essas decisões, obviamente, afetarão a estrutura de custos do nosso modelo de negócios.

Atividades-Chave:

  • Selecionar e priorizar projetos
  • Gerenciar portfolios
  • Prover treinamento, coaching e mentoring
  • Desenvolver políticas, metodologia e templates
  • Prover ambiente de TI para gestão de projetos (EPM)

 Recursos Principais

  • 01 Diretor de projetos
  • 02 Gerentes de projetos seniores
  • 02 Assistentes de Planejamento
  • 01 Profissional de TI (EPM)

 Parcerias Estratégicas:

  • Empresas de treinamento e consultoria (terceirizar treinamentos)
  • Departamento de RH (plano de carreira, cursos etc)
  • Departamento de TI (infraestrutura – computadores, rede etc)
  • Associações como PMI, IPMA etc (seminários, padrões etc)

 Estrutura de custos:

  • Salários
  • Sala, infraestrutura
  • Software
  • Livros e publicações
  • Consultoria e Treinamentos

 

Figura 3 – Modelo de Negócios para PMO

 Bem, essa é uma idéia inicial, bastante simplificada, de um modelo de negócios para escritórios de projetos. A proposta precisa ser aperfeiçoada, com certeza. Todavia, acreditamos que utilizar o canvas do Business Model Generation, bem como técnicas de Design Thinking, modelagem de processos de negócios e outras, é extremamente útil para definir estruturas organizacionais uteis e que agreguem valor. Do contrário, implantar PMOs sem analisar e pensar sua estrutura e funções, é apenas seguir um modismo…

Nos próximos posts, conversaremos um pouco sobre a recuperação de projetos “fracassados”. Você já entrou em um projeto que já estava em andamento? Ele estava com problemas? O gerente abandonou o projeto e você precisou assumir? Se isso ainda não aconteceu contigo, pode ter certeza de que um dia vai acontecer! Por isso, não percam nossos posts sobre recuperação de projetos. Até lá!

 

 

Just Start – Decidindo na Incerteza

 

Existe um texto fantástico do Roberto Shinyashiki cujo título é “O sucesso é construído à noite! Durante o dia você faz o que todos fazem.” Neste texto, Shinyashiki aborda os pilares do sucesso: planejamento, perseverança e persistência. Esses 3 P´s são necessários mas não suficientes para garantir o sucesso. A execução dos nossos planos pessoais e profissionais depende em grande parte de ação e atitude, tema do livro Just Start: Take Action, Embrace Uncertainty, Create the Future (Schlesinger; Kiefer; Brown, 2012). Os autores propõem o ciclo Agir-Aprender-Construir (Act-Learn-Built) em contraposição ao famoso PDCA (Plan-Do-Check-Act).

Em outras palavras, o planejamento está se tornando cada vez mais ágil, flexível e adaptável. Agir (Act) significa escolher deliberadamente um caminho (veja posts sobre Tomada de Decisão) e envidar todos seus esforços nesse sentido. Não se trata agir ao acaso, escolhendo caminhos aleatoriamente. Trata-se de exercer e desenvolver as competências mais importantes para os profissionais na atualidade:

  • Decidir na complexidade
  • Agir na incerteza

Em se tratando de tomada de decisão e métodos de estruturação de problemas, existe vasta literatura, como o artigo do Prof Ion Georgiou (FGV): Making Decisions in the Absense of Clear Facts (Georgiou, 2008 – EJOR). A ação (Act) proposta por Schlesinger, Kiefer e Brown (2012), portanto, é o primeiro passo, mas deve ser baseado em método.

O passo seguinte no ciclo Act-Learn-Build é aprender a partir da ação tomada, isto é, coletar e refletir sobre as lições aprendidas. O terceiro e último passo é construir (Build) sobre o aprendizado. Tanto nos passos de aprendizado quanto de construção, poderíamos aplicar métodos de estruturação de problemas e tomada de decisão. Eu sugiro, inclusive, pensar no ciclo PDCA dentro do ciclo Act-Learn-Build.

 

Figura 1 – Act-Learn-Build

 Quando não é possível planejar detalhadamente, temos duas opções: 1) não fazer nada e permanecer “empacado”; 2) agir para obter mais informações e depois replanejar. A segunda opção é o que propõe o ciclo Act-Learn-Build. Agir para diminuir incertezas, reduzir riscos e obter maior conhecimento sobre a situação. Poderíamos fazer uma analogia com Strategic Choice Approach (Friend, 2005), buscando reduzir três fontes de incerteza na tomada de decisão:

  • Incerteza quanto aos Valores
    • Compreender os objetivos e diretrizes
    • Clarear expectativas e agendas
    • Definir prioridades
  • Incerteza quanto ao Ambiente
    • Coletar informações
    • Estimar, prever, investigar e analisar
  • Incerteza quanto a Decisões Relacionadas
    • Coordenar, planejar e negociar

Ou seja, agindo sobre o ambiente (Act), podemos aprender sobre ele e sobre nós (Learn), definindo o que realmente desejamos fazer para depois construir ou reconstruir o plano (Build) e o executar. Embora isso tenha um pouco cara de “fazejamento”, algo que abominamos, não se trata disso. Trata-se de experimentação e proatividade, coisas importantíssimas, mas que devem ser utilizadas em ocasiões adequadas e com certa parcimônia…

Concluindo, Schlesinger, Kiefer e Brown (2012) pregam a importância de executar, colocar a mão na massa, reforçando o movimento ágil e lean. Identifique o valor e faça coisas para construí-lo e o capturar em seus projetos sempre. O livro Just Start traz sugestões de como aplicar o framework não apenas aos negócios mas também às nossas vidas pessoais, muito bacana. Recomendo a leitura do livro (ver também artigo na HBR: New Project? Don´t Analyze – Act).

 

IBM lidera o ranking americano de patentes pelo 20° ano consecutivo

IBM lidera o ranking americano de patentes pelo 20° ano consecutivo

Pesquisadores da IBM registraram patentes em áreas-chave da tecnologia, como análise de dados, big data, cloud computing e mobilidade 

 

São Paulo – 10 Jan 2013: A IBM (NYSE: IBM) anuncia hoje sua liderança no ranking de registro de patentes, pelo 20º ano consecutivo, atingindo recorde de 6.478 patentes em 2012 com invenções que permitirão avanços fundamentais em áreas-chave do mercado de tecnologia, como análise de dados, Big Data, segurança de sistemas, computação em nuvem, mobilidade e redes sociais, além de soluções focadas nos setores varejista, financeiro, de saúde e transporte. As invenções patenteadas também significam um importante avanço na transformação da computação, conhecida como era de sistemas cognitivos.

A conquista do recorde em patentes foi possível graças ao trabalho dos mais de 8.000 inventores da IBM de 46 estados dos Estados Unidos e de outros 35 países, incluindo o Brasil. Pesquisadores que residem fora dos EUA contribuíram com cerca de 30% do montante alcançado em 2012. De 1993 a 2012, os inventores da IBM registraram mais de 67 mil patentes somente nos Estados Unidos.

“Estas duas décadas de liderança em patentes nos Estados Unidos demonstram o compromisso de um século da IBM com pesquisa e desenvolvimento. Este recorde é a concretização da dedicação da empresa à inovação, que conta com investimento anual de cerca de US$ 6 bilhões, essencial para nossos clientes, nossa companhia e para o mundo”, diz José Carlos Duarte, CTO da IBM Brasil.

A produção recorde de patentes da IBM em 2012 inclui invenções que estão redefinindo a maneira como as companhias aplicam a tecnologia no atual contexto de um Planeta Mais Inteligente (Smarter Planet), constituindo as bases para a nova era de sistemas cognitivos. Algumas das invenções interessantes e importantes do total de patentes da IBM em 2012 incluem:

  • Sistema e método para proporcionar respostas a perguntas: Esta invenção patenteada foi implementada no sistema IBM Watson e descreve uma técnica que permite a um computador captar uma pergunta em linguagem natural, entendê-la detalhadamente e dar uma resposta precisa à pergunta.
  • Sinapse de aprendizagem eletrônica com plasticidade atrelada ao tempo dos potenciais pré e pós-sinápticos (STDP), utilizando elementos de comutação de memória unipolar: Esta patente se relaciona com algoritmos e circuitos para imitar de forma eficiente a função de aprendizagem das sinapses do cérebro. A IBM está trabalhando em um projeto de computação cognitiva chamado Neuromorphic Adaptive Plastic Scalable Electronics (SyNAPSE), que emula as capacidades de percepção, ação e cognição do cérebro, enquanto consome menos ordens de magnitude de potência e volume sem programação.
  • Sistema e método para otimizar o reconhecimento de parâmetros não gaussianos: Esta patente descreve uma técnica para tratar e reconhecer padrões em conjunto de Big Data, como a compreensão de frases faladas ou o processamento de dados de satélite, para predizer a localização de engarrafamentos de trânsito.
  • Métodos, sistemas e produtos de programas de computação para sintetizar informação de procedimentos médicos em bancos de dados de atendimento de saúde: Esta invenção descreve uma técnica que permite aos profissionais de saúde ter acesso e analisar com mais eficiência dados médicos e históricos clínicos armazenados em múltiplas fontes diferentes de dados, melhorando sua capacidade de pesquisar, diagnosticar e tratar problemas de saúde.
  • Modelagem de implementação simplificada de aplicativo dinâmico em ambientes de centro de processamento de dados: Estas invenções patenteadas descrevem um Entorno Definido por Software composto por uma plataforma de modelagem para definir componentes de aplicativos com seus requisitos e características, e um sistema de orquestração inteligente para implementar, atualizar e administrar de forma dinâmica cargas de trabalho. As invenções permitem à família de produtos IBM PureSystems utilizar padrões que agilizem a implementação e otimizem a gestão do ciclo de vida de cargas de trabalho.
  • Redução do consumo de energia em um ambiente de computação em nuvem: Esta invenção descreve uma técnica que permite o uso mais eficiente e efetivo dos recursos de computação em nuvem, com a consequente redução e minimização do consumo de energia.
  • Fabricação de substrato ultrafino utilizando spalling de substrato induzido por pressão – Esta patente descreve um método de baixo custo para fabricar uma nova classe de materiais semicondutores flexíveis que poderão ser aplicados em produtos ultrafinos, de peso leve, e utilizados em uma ampla gama de tecnologias como biomedicina, segurança e iluminação.
  • Viabilização de um conjunto de códigos de acesso através de um dispositivo – Esta invenção é baseada num método para validar e recuperar códigos (válidos apenas por um período muito curto) que visam melhorar a segurança do sistema através de uma rede móvel (por exemplo, SMS), por meio de um canal encriptado a partir de um servidor seguro, permitindo, por exemplo, completar uma transação segura ou realizar operações de login seguro num telefone móvel.

 Clique aqui para visualizar o gráfico com os Líderes de patentes nos Estados Unidos em 2012*

* Dados proporcionados por IFI CLAIMS Patent Services

Social Project Management

Social Project Management

Gerenciando tarefas das equipes em ambientes sociais.

 

 

 

 

 

 

 

 

 

 

Os aplicativos para gerenciamento de atividades de projetos em redes sociais estão proliferando na internet. Plataformas que tem tarefas como foco central do aplicativo, gerenciando as atividades das equipes de projetos através de compartilhamentos online de tarefas entre os grupos de pessoas da empresa. Um software na nuvem que reúne pessoas em torno de um trabalho específico dentro da empresa, que faz uso dos ambientes em redes sociais para trazer aplicação prática e resultado as corporações.

Algumas dessas ferramentas estão mais baseadas no gerenciamento do dia-a-dia das atividades e outras mais voltadas para a estratégica e planejamento de recursos para ações de médio prazo. Entre elas estão, 10,000ft  (http://www.10000ft.com/), Do.com (https://www.do.com/), Asana (http://asana.com/ ), Wrike http://www.wrike.com/pt_BR/  e no Brasil um exemplo semelhante é o Artia (http://artia.com/), Sparqlight (https://www.sparqlight.com)   entre outros.

 

Típico ambiente de compartilhamento social de atividades – Asana Software.

 

Como parte de um esforço maior em tornar os softwares de ambientes sociais mais focado em resultado prático. Buscando a organização do trabalho diário a ser realizado e uma maior visibilidade das responsabilidades individuais com a sua rede de relacionamento social corporativa. Estas empresas oferecem seus aplicativos como uma nova força das redes sociais a ser incorporada pelas empresas. Essas ferramentas abrem uma nova abordagem de colaboração entre pessoas dentro de um contexto corporativo. As redes sociais inicialmente buscavam foco em fazer negócios, contatos e depois compartilhar suas experiências agora desloca seu objetivo para a organização e distribuição de atividades entre pessoas de grupos sociais corporativo.

Para muitos, “social business” é um oximoro, ou seja, palavras de sentido contraditório. As pessoas precisam enxergar seu gráfico de trabalho ao invés de seu gráfico social. Elas precisam saber no que estão trabalhando, todas as coisas que já realizaram e com que parte está comprometida, quais suas próximas metas e como tudo isso contribui para o sucesso do projeto.

Estas ferramentas, os chamados ambientes “Post-2.0” vão além dos blogs, wikis e RSS feeds. Foram impulsionadas pelos usuários de redes sociais acostumados com ambientes como Facebook habilitaram a criação desses ambientes corporativos colaborativos, que exige muito pouco treinamento das pessoas para utilizá-los. O que possibilitou a noção de “Activity feed updates”, ou seja, posts de usuários fazendo atualização de suas atividades compromissadas junto as suas redes de relacionamentos. Estabelecendo assim ambientes sociais com mais poder de execução, colaboração e senso de suas esferas de responsabilidades perante o projeto.

Texto baseado em matérias publicadas em:  http://www.informationweek.com

 

Redação Revista MundoPM

Um Gerente de Projetos no Canadá

Conversando com nosso amigo Paulo Camargo, encontrei insights muito interessantes sobre o gerenciamento de projetos como tendência global e sobre os profissionais de GP como força motriz desse processo. O mais bacana é ver colegas expatriados mostrando a capacidade dos brasileiros mundo afora.

Paulo começa respondendo as primeiras perguntas iniciais sobre “Como é gerenciar projetos no Canadá? É muito diferente?”. Depois ele comenta suas percepções sobre o gerenciamento de projetos e nos deixa dicas valiosas. Leiam a transcrição a seguir.

PAULO: gerenciamento de projetos é gerenciamento de projetos em qualquer lugar do mundo, os problemas e situações que encontramos no dia a dia são praticamente os mesmos – caso contrário não teríamos instituições como PMI, IPMA ou o OGC Britânico criando melhores práticas (Caso do PMI) ou metodologias (PRINCE2) aplicáveis em qualquer parte do mundo. Entretando, algumas das diferenças que percebi durante esses 3 anos atuando como GP no Canadá foram:

1. O Gerente de Projetos é reconhecido pelo Mercado. Ele é o responsável pelo projeto, sendo valorizado e respeitado como tal. Como a função do GP é conhecida pela maioria dos membros da equipe, fica muito mais fácil acompanhar e cobrar as entregas. Já ouvi várias vezes o GP ser chamado de “Cola” que mantém a equipe do projeto unida e informada, sem ele o projeto simplemente “não anda”.

2. Planejamento: As empresas e instituições em que trabalhei aqui realmente investem tempo e recursos nessa fase – algumas vezes contratando empresas terceiras para ajudar na elaboração do orçamento do projeto, por exemplo – E Novamente, o papel do Gerente de Projetos de juntar todas as partes do projeto e dar um “corpo” a ideia original é essencial. Falando um pouco do processo de planejamento: algumas instituições possuem sua própria metodologia para essa importante fase do projeto (Caso da Prefeitura da Cidade de Calgary) e outras se baseiam na experiência do GP,deixando-o a vontade para elaborar o plano do projeto da maneira que achar melhor.

3. Fornecedores: Tenho observado uma tendência maior de se exigir que os fornecedores tenham um padrão ou metodologia de gerenciamento de projetos bem definida. Esse é um diferencial que pode determinar o vencedor de uma licitação: a qualidade do processo de gerenciamento de projetos. Como o fornecedor vai entregar o plano do projeto? Como será a comunicação entre as empresas durante o projeto? Quais ferramentas o fornecedor disponibilizará para o cliente acompanhar o andamento físico / financeiro do projeto? Como são pouquíssimas as empresas que possuem certificaçao ISO aqui no Canadá, as empresas que apresentam os processos documentados são realmente vistas como especiais.

4. Gerenciamento de projetos é um item bem definido nos orçamentos anuais da empresa e de todos os seus projetos. Enquanto no Brasil eu dificilmente idenficava a linha “Gerenciamento de Projetos” em orçamentos, aqui isso já é automático, para cada projeto, existe um orçamento específico para o Gerenciamento do Projeto (recursos humanos + materiais).

5. Dependendo do escopo do projeto, um analista de negócios costuma fazer parte da equipe do projeto: assim o GP pode focar na administração do projeto e não na sua documentação. O Analista de negócios é responsável por essa atividade entre outras. Outra coisa que me chamou muito a atenção é que o analista de negócios é quem participa ativamente no gerenciamento das espectativas das partes interessadas. Como esse profissional possui formação específica para mapeamento de processos (mapeamento, identificação de “gaps”, análise e melhorias) é ele quem tem mais contato com os envolvidos e portanto entende as expectativas das partes interessadas, ajudando o GP a gerenciá-las. Em alguns projetos o Analista de Negócios acaba sendo a “cara” do projeto. Essa foi uma situação inusitada para mim em um dos recentes projetos que gerenciei – a implantação da ferramenta MS-Lync para 2.000 usuários – e que causaria uma mudança enorme para os usuários finais: a desinstalação do PABX e retirada dos telefones de plástico de todas as mesas e a implantação de um novo software e fones de ouvido como meio de comunicação.

6. Os patrocinadores normalmente conhecem seu papel e importância nos projetos e são bastante atuantes. Para resumir, podemos afirmar que a maturidade em Gerenciamento de Projetos das instituições em geral no Canadá, contribui para o andamento melhor dos projetos, ajudando bastante o GP em seu papel de realizar as entregas e deixar as partes interessadas felizes e satisfeitas com os resultados.

Além de agradecer o Paulo pelo seu tempo e informações ricas, eu gostaria de convidar nossos amigos leitores a uma reflexão sobre os comentários feitos por ele. Obviamente, no Brasil, como em todos os outros lugares, temos “ilhas de excelência”. Paulo, por ser um bom profissional, certamente está em alta nos círculos de projetos do Canadá.

Todavia, algumas de nossas empresas ou mesmo instituições públicas ainda estão iniciando ou patinam em maturidade e capacidade de gerenciamento de projetos. Recentemente, recebi um email de uma colega que está “lutando” para implantar melhores práticas na organização em que ela trabalho. Isso é natural. Trata-se de uma mudança não apenas de processos e organização, mas principalmente de uma mudança cultural profunda que exige o melhor do Change Management para funcionar bem.

No item 2, quando Paulo fala de instituições que possuem suas próprias metodologias, achei interessantíssimo. Essa é uma bandeira que eu e muitos profissionais defendemos: customização, adaptabilidade e flexibilidade. As melhores práticas, guias, métodos, ferramentas, técnicas e metodologias são sugestões de coisas que funcionam bem em algum lugar do planeta. Isso não significa que devem ser implementadas ipsis litteris na sua organização. Em um post sobre a abordagem Strategic Project Leadership, mencionamos as palavras de Shenhar: “if you manage your project by the book, you´ll probably fail.”

As abordagens contingenciais, o crescente aumento de complexidade e velocidade nos ambientes interno e externos dos projetos são uma realidade da qual não podemos olvidar.

Também gostei bastante dos comentários do Paulo a respeito dos Fornecedores e sua importância. Outra prática importante é designar recursos (materiais, pessoas e tempo) para o gerenciamento do projeto. Atividades de coordenação, reuniões, comunicação, monitoramento e controle, entre outras, são extremamente importantes e não podem ser prescindidas.

Finalmente, no item 5, Paulo menciona uma questão bastante controversa sobre os limites do trabalho do gerente de projetos, o que me faz lembrar a velha discussão GP técnico versus GP generalista, algo que pode ser assunto de outro post. Vejo com bons olhos e acho bastante valiosa a contribuição dos analistas de negócios e sua crescente profissionalização por meio de organizações como o IIBA, que já possui Chapters no Brasil. O gerenciamento de projetos não é algo estanque, não é separado do restante da organização. Gerenciar projetos faz parte dos processos de negócios (projeto deve agregar valor, lembra?) no contexto maior da empresa e sua estratégia. Desta forma, eu vejo como uma tendência que os projetos sejam cada vez mais multidisciplinares, interdepartamentais e possam até mesmo envolver consórcios, parcerias e colaboração de diferentes instituições públicas e privadas (vejam NETLIPSE, por exemplo).

O último item que o Paulo levantou trata dos patrocinadores, uma peça-chave em minha opinião. O sponsor é um link estratégico no projeto, algo que fica bastante claro no PRINCE2 e é tratado em diferentes literaturas, especialmente por Englung e Bucero (2006). Stakeholders e comunicação continuam sendo a bola da vez nos projetos, exatamente por causa das facetas que mencionamos anteriormente em projetos e programas cada vez de maior monta. Os verdadeiros desafios atuais não estão apenas na complexidade técnica, tecnológica e de recursos, mas sim e principalmente em criar valor e mostrar o valor criado.

Na próxima semana, vou completar a trilogia do PMO Model Generation. Andei pensando bastante sobre o assunto, obtive feedbacks positivos e acredito que poderemos aprender bastante juntos aplicando modelos de negócios a diferentes áreas do gerenciamento de projetos. Até lá!