Para grande problema, pequena solução.

A tendência para resolver grandes problemas é definir grandes soluções.
Só que grandes soluções por vezes implicam grandes mudanças e grandes mudanças quase sempre implicam ficar tudo na mesma.

Assim para um problema de extrema complexidade de resolução devemos tentar definir uma pequena solução, solução essa que faça minorar o problema, que dê inicio à mudança.

É o que Chip e Dan chamam de "Bright Spots".

Foi o que fez Jerry Sternin no Vietname ao lidar com o problema complexo da má nutrição das crianças vietnamitas.

Antes da visita de Jerry ao Vietname já muitos analistas tinham verificado o problema que estava relacionado com a falta de saneamento básico, a pobreza, ignorância, etc.
Elaboraram detalhados planos para a sua resolução para no fim nada ter mudado.

Jerry por sua vez tentou uma abordagem diferente, misturou-se na população na tentativa de encontrar crianças bem nutridas mas com os mesmos meios e dificuldade de todas as outras. No fundo tentou encontrar casos de sucesso, bright spots!

E encontrou! De forma a descobrir qual a diferença analisou qual os hábitos alimentares padrão de todas as crianças: Comiam 2 refeições por dia, baseada em arroz de melhor qualidade e deixada à descrição das crianças para comerem o que desejassem.

Por sua vez, nas famílias com crianças bem nutridas, a mesma dose de comida era divida em 4 refeições diárias onde os pais obrigavam as crianças a comer toda a comida, mesmo quando doentes. Comiam igualmente pequenos camarões e caranguejos em abundância no Vietname mas onde se acreditava que era comida muito pesada para as crianças.

Era esta a diferença entre dietas que ditava a boa nutrição das crianças. Ao dividir a comida por 4 refeições mais pequenas as crianças conseguiam absorver mais nutrientes e os camarões e caranguejos forneciam proteínas e vitaminas essenciais.

Estava descoberta uma pequena solução que podia ser implementada com os meios disponíveis no Vietname.

Jerry começou a realizar em diversas vilas eventos onde as mães aprendiam a cozinhar a nova dieta e dada uma altura a palavra foi passando por todo o Vietname. Mais de 2 milhões de pessoas foram influenciadas pelo programa e mais de 65% das crianças melhoraram a sua condição.

Sempre que tiverem um grande problema, que requer que muito mude, Tentem descobrir primeiro casos de sucesso. Será assim a melhor maneira de começar a mudança.

Artigo sobre a mudança

Já que temos vindo a falar sobre mudança deixo aqui um artigo do Jornal de Negócios sobre o tema.

Ler artigo Mudança

Gestão Mudança - Factores Críticos de Sucesso

Tenho escrito muito sobre gestão de mudança nos últimos tempos. Fruto do livro de Chip e Dan sobre o assunto que classifico de "simplesmente extraordinário".

Faço aqui um resumo dos factores críticos de sucesso que segundo os autores têm de ser trabalhados para a mudança acontecer, seja ela pessoal, na família, na organização ou na sociedade.

Seguindo a analogia dos autores, para termos uma mudança bem sucedida temos que direccionar o piloto, motivar o elefante e marcar o caminho.

1. Direccionar o piloto, pois sabemos que o lado racional de todas as pessoas tem tendência para analisar em demasia o que pode levar o elefante a andar em círculos. Lembrem-se do caso de sucesso da campanha "Continue a beber leite mas magro" aqui.

2. Motivar o elefante, ou o lado emocional das pessoas. Sabemos que para a mudança acontecer é necessário mudar velhos hábitos que exigem Auto-controlo, um recurso que se esgota. Assim é fácil o poderoso elefante mudar para um caminho diferente do piloto. Lembrem-se do caso de sucesso na "Compra de luvas" aqui.

3. Marcar o caminho, sabemos que para uma mudança acontecer a circunstância deve ser favorável. Lembrem-se da história do "Balde de pipocas" aqui.

O poder de um caminho bem definido

Mais um caso numa mudança bem sucedida e que exemplifica o poder de ter um destino bem definido.

Já sabemos que o piloto das pessoas tem tendência para a análise continua, para pedir mais informação, para recolher opções sem nunca escolher uma. O piloto tem tendência para forçar o elefante a andar às voltas.

Dois investigadores nos EUA pretendiam reduzir o consumo de gorduras saturadas para os níveis recomendados. As publicidades governamentais habituais passavam mensagens genéricas como "Seja mais saudável".

Este tipo de mensagem provoca nos pilotos das pessoas diferentes interpretações: Fazer mais exercício, deixar de lanchar, comer mais fruta, etc.

São mensagens que fazem o piloto andar com o elefante às voltas devido às infindáveis opções.

Os investigadores descobriram que os Americanos são grandes consumidores de leite. O leite é uma grande fonte de gordura saturada. Bastava os americanos na sua dieta trocarem o leite comum por leite magro para passar a ingerir gordura saturada em níveis recomendados.

Os investigadores tinham agora uma mensagem clara a passar aos Americanos, um destino bem definido para os seus pilotos: "Continue a beber leite, mas magro".

Agora bastava passar a mensagem, não a colocaram no frigorífico das pessoas mas nos supermercados onde a escolha é irremediavelmente feita.

Os resultados num projecto-piloto foram surpreendentes: O consumo de leite magro passou de 18% para 41%. Seis meses mais tarde e sem campanhas o consumo estabilizou nos 36%.

Mais um exemplo do poder de um caminho bem definido na gestão de qualquer mudança.

O poder de falar para o piloto e elefante

Vimos nas mensagens anteriores a importância de numa mudança guiar o piloto e motivar o elefante.

Chip e Dan no seu livro exemplificam o poder de quando conseguimos direccionar o piloto e motivar o elefante.

Contam a história de um colaborador de uma grande empresa de fabricação que acreditava que o processo de compra da empresa não era o mais adequado.

Este colaborador escolheu um item do processo de compras, luvas que se usava em várias fábricas. Descobriu que a empresa comprava 424 marcas diferentes de luvas e que os preços variavam entre 5$ e 17$.

Para provocar a mudança o colaborador fez um painel onde colocou várias luvas de diferentes marcas e diferentes preços.

De seguida convidou todos os directores a analisar o painel. O resultado foi brilhante, os directores não tinham palavras e a história do painel começou a correr a empresa. Vários colaboradores deslocavam-se de propósito para ver o painel.
A conclusão foi única, todos acharam que o processo de compra era ridículo.

O colaborador não só trabalhou o piloto dando uma solução.
Realizou a apresentação das luvas num painel que colocou o elefante em fogo, pronto para mudar.

Será que teria conseguido com uma apresentação em PowerPoint?

Penso que muitas vezes tentamos explicar aos outros que necessitamos de mudar algo, apresentamos razões lógicas, vantagens que são evidentes onde as pessoas concordam connosco todavia nada acontece. A razão é que muitas vezes apenas trabalhamos o piloto e sabemos agora que o piloto apenas consegue guiar o elefante por pouco tempo.

Assim torna-se fundamental atingir o coração das pessoas quando queremos uma mudança. São as emoções que movimentam o elefante, a motivação.

E esta é a parte difícil da mudança, saber o destino é fácil, é senso comum, é mudar o que está mal, em certos casos até uma criança o consegue definir.

A parte difícil, e quase sempre esquecida é motivar o elefante.

2º surpresa sobre a mudança

Esta mensagem é a continuação de 1º surpresa sobre a mudança

Chip e Dan no seu livro sobre a mudança fazem uma analogia muito engraçada de como uma mudança deve ser bem sucedida. Nas suas opiniões uma mudança (um destino) deve ser trabalhada em 3 frentes:

1. Guiar o piloto;
2. Motivar o elefante;
3. Moldar o caminho;

Ou seja, para acontecer uma mudança, ou conseguirmos levar o elefante a um determinado sítio temos de definir claramente o caminho ao piloto. Todavia para chegar ao destino não basta conhecer a sua localização no mapa. O elefante é um animal enorme e a maioria das vezes o piloto não tem controlo no elefante.

Assim teremos que motivar o elefante a percorrer o caminho, caminho esse que deve ser propenso a ser percorrido.

Quando Chip e Dan falam do piloto, falam sobre o lado racional das pessoas, o lado consciente, o lado que necessita de auto-controlo sempre que funciona. O que acontece em muitos projectos, é que as pessoas não sabem bem o que se espera delas, o que devem fazer, como podem ajudar. O que acaba por acontecer é que acabam por andar com o elefante às voltas, sem sair do mesmo sitio, ficam paradas.

Assim, em qualquer mudança deve haver uma definição clara do que se pretende das pessoas, para que o piloto saiba aonde deve levar o elefante.

O elefante é o oposto da parte racional, é o lado emotivo, é o lado que funciona em piloto-automático. Como elefante que é tem o poder de conseguir contrariar o piloto.

Consegue muitas vezes contrariar o piloto porque como vimos na mensagem anterior, para a mudança acontecer, tem de ser contrariadas rotinas diárias, que funcionam em piloto-automático, e para as contrariar gasta-se Auto-controlo que sabemos agora que é finito. Quando isto acontece o piloto deixa de controlar, e o poderoso elefante assume as rédeas.

E para o elefante chegar ao destino é necessário que o caminho facilite a viajem.

Na minha mensagem 1º surpresa sobre a mudança expliquei como se pode ajudar a moldar um caminho num projecto TI.

Um exemplo prático:

Imagine que decide ter uma vida mais saudável e define para 2011 o objectivo: "Passar a ter uma vida saudável"

Como será recebida a mensagem no seu piloto? Andará com o elefante às voltas sem saber que caminho percorrer. Porque? Porque "Passar a ter uma vida saudável" é genérico, é TBU - True But Useless, simplesmente não é claro.

Agora se definirmos que em 2011 não vamos mais fumar, estamos a definir uma regra clara que pode ser avaliada e medida e que contribui para uma vida mais saudável. O piloto sabe qual o destino.

E aqui fica a 2º surpresa sobre a mudança, quando ouvir as pessoas a reclamarem que a mudança é difícil porque as pessoas são preguiçosas, pode ser porque o caminho não está claramente definido para o piloto das pessoas.

1º surpresa sobre a mudança

Sabemos como é difícil a mudança quer a nível pessoal, quer numa organização. Conheço muitos projectos de sistemas de informação em que os utilizadores finais dificultam o projecto, pois esta traz alterações a métodos de trabalho com muitos anos.

Muitos destes problemas por vezes não têm a ver apenas com as pessoas mas com a situação em si. Chip & Dan no seu livro Switch afirmam que muitas vezes a própria circunstância em que a pessoa se insere pode ser mais ou menos favorável à mudança.

Conseguem demonstrá-lo com um estudo em que colocam dois grupos de indivíduos no cinema.
A um grupo é dado um balde de pipocas médio e a outro grupo é dado um balde de pipocas gigante. Apesar de terem dimensões diferentes cada tipo de balde tem mais pipocas que alguma pessoa poderia comer. O grupo com o balde maior acabou por comer mais 57% do que o grupo com o balde médio. Com isto provaram que somos influenciados (até o próprio apetite) pela circunstância em que estamos inseridos.

Para mim isto não é novidade, por vezes questionei-me se tivesse nascido no seio de uma família de assaltantes me levaria a tornar no assaltante.

Chip & Dan defendem assim que a 1º surpresa na mudança é que muitas vezes esta é difícil não porque o problema seja as pessoas, mas talvez porque não esteja criado uma atmosfera favorável à mudança.

Na nossa área de sistemas de informação temos obrigação de gerir esta atmosfera.

Para não me chamarem um teórico apresento algumas iniciativas que poderão ajudar:

1. Formação aos utilizadores finais;
2. Formar key-users ou utilizadores finais que serão verdadeiros especialistas da aplicação e que poderão ajudar os outros colegas;
3. Linha de apoio onde os utilizadores poderão colocar dúvidas e obter uma resposta rápida;
4. Manual de utilização;
5. Um formador presente no dia-à-dia nos primeiros tempos;
6. Empenhamento forte das chefias na mudança;

Como podem ver as soluções são do senso comum mas muitas vezes são esquecidas. Ao aplicarmos estas ideias e outras estaremos a formar uma atmosfera mais favorável à mudança.

Gestão de Mudança - Auto Controlo

A mudança é talvez a parte mais difícil de um projecto. Mudança será o tema dos meus próximos posts pois penso ser a parte mais complicada da maioria dos projectos. Tenho estado a ler o livro "Switch - How to change things when change is hard". Os autores, Chip e Dan Heath começam por explicar o motivo pela qual a mudança é difícil para qualquer pessoa. Mudança, seja a nível pessoal ou organizacional implica um esforço consciente para mudar hábitos diários enraizados. Este esforço consciente é chamado de Auto-controlo.

Descobriu-se há pouco tempo que o Auto-controlo de uma pessoa é um recurso que se esgota à medida que se usa ao longo do dia. No fundo tudo o que se faz de forma automática, o que é habitual e quase nem se pensa, não gasta este recurso, todavia se assumir o controlo das suas acções para contrariar um velho hábito está a gastar auto-controlo. Assim é normal que muitos de nós, depois de ultrapassar tarefas super-complexas durante o dia, tenhamos dificuldade em lavar uma simples loiça depois de jantar.
Esta descoberta foi conseguida através de uma experiência em que colocaram vários indivíduos numa sala com bolos de chocolate com um cheiro apetitoso e rabanetes. Os indivíduos foram instruídos para comerem apenas as bolachas e de forma alguma comerem os rabanetes. A outro grupo foi pedido o oposto, comerem os rabanetes sem tocarem nas bolachas. No final da experiência todos os indivíduos cumpriram o que foi pedido.

Depois da primeira parte foi pedido aos dois grupos que tentassem resolver um puzzle impossível de resolver, embora não soubessem. O grupo que comeu as bolachas aguentou o dobro do tempo a tentar resolver o puzzle até desistir do que o grupo 1. Com esta experiência conseguiram provar que o grupo 2 ao usar o Auto-controlo para não comer as bolachas de chocolate esgotaram parte do seu recurso para aguentar mais tempo a tentar resolver um puzzle.

Nos próximos posts irei explicar como, na opinião dos autores, deveremos enfrentar uma mudança com probabilidades de sucesso maiores.

Como impressionar numa apresentação

Deixo aqui aos nossos leitores 5 princípios a seguir quando se faz uma apresentação em que se pretende captar a atenção da audiência.

http://www.presentationzen.com/presentationzen/2010/10/start-your-presentation-with-punch.html

O que é um PPM (Project Portfolio Management)?

Um “Programa de Gestão de Portfolio de Projectos (PPM)” é um sistema concebido para, num primeiro nível, ajudar uma organização a manter, gerir e agregar as informações sobre todos os seus projectos. Essa visão global, integrada, metódica e precisa dos projectos, irá permitir classificar e priorizar cada projecto, de acordo com critérios estabelecidos na organização (tais como valor estratégico, impacto sobre os recursos, custo, risco, etc) de forma a maximizar, em cada momento, o valor obtido pela ordem de execução dos projectos.

Os objectivos do PPM são:

1) Reunir o conhecimento de todos os projectos de uma organização (independentemente da fase em que estão) de uma organização.

2) Permitir uma compreensão mais exactas do conjunto de projectos, adequando a visão (nível de agregação da informação) a cada nível de gestão/direcção da organização.

3) Permitir melhores decisões (por exemplo, adiando ou antecipando projectos) de acordo com seus custos, benefícios, riscos, alinhamento com estratégias de longo prazo, objectivos de gestão e restrições (limites) dos recursos da organização.

4) Maximizar o retorno obtido pela realização dos projectos.

Se pretendemos olhar para os projectos de uma forma integrada, garantir o alinhamento das actividade com a estratégia da empresa, não podemos deixar ter um sistema PPM.

Concordam?

Um exercício interessante

Façam uma pesquisa no Google por “Project management success factors”, listem 10 factores que encontrarem aleatoriamente. Depois verifiquem para cada factor até que ponto a vossa organização se encontra alinhado com este. Senão está alinhado quais os pontos que impendem esse alinhamento. É um exercício engraçado que no fim permite compreender a Big Picture da Gestão de Projecto da organização.

Equilíbrio entre formalismo e liberdade

Ainda sobre a rigidez dos processos de negócio, as empresas de sucesso vivem num equilíbrio entre formalismo e liberdade. Vamos supor que uma empresa X de retalho, compra um produto A que todas as cadeias de retalho comercializam. A central de compras compra este produto por 2 €, e é responsável por determinar o seu preço final em todas as lojas, neste caso 3€. As lojas da empresa de retalho não têm o controlo sobre o preço do produto. Temos neste caso um processo de definição de preço que está centralizado na empresa. O que pode acontecer?
As lojas, a periferia da empresa, quem está no terreno e melhor conhece o mercado local perdem flexibilidade. O que pode fazer o gerente da loja se o concorrente ao lado vender o produto A a 2,5€?
Apenas solicitar à Central de Compras que altere o preço, entrado numa cadeia de decisão que se não for rápida levará a empresa a perder tempo para o mercado.
Não estou contra decisões descentralizadas, estou a favor de decisões no local onde mais informação existe e com a rapidez que se entende necessária.
Neste caso, poderíamos ter uma central de compra preocupada apenas em que uma venda tenha de gerar um lucro e a impor um preço mínimo ao produto, mas deveria ser a loja (no terreno) a estabelecer um preço final, deslocando assim a decisão para a periferia.

Onde se toma as decisões?

Estou neste momento a ler um livro muito interessante: "O efeito das checklists" e li algo bastante interessante. Onde deve se tomar certas decisões? No centro da empresa, ou na periferia (no terreno)?
Claro que se trata de uma questão que varia de situação para situação, mas a verdade é que muitas vezes o nosso estado centraliza decisões, para departamentos e pessoas que não estão no terreno e que não conhecem a realidade. Assim o poder de decisão acaba por ser moroso e a decisão quando acontece acaba muitas vezes por ser errada.

Gawande no seu livro exemplifica esta questão com o furacão Katrina. Na Flórida uma grande cadeia de produtos alimentares e perante o cenário de catástrofe decidiu descentralizar as decisões passando-as para os gerentes de cada loja. O CIO da empresa afirmou mesmo que deviam tomas decisões difíceis perante as informações que tinham no terreno. As lojas acabaram a fornecer medicamentos aos hospitais e a fornecer bens essenciais à população local com base num sistema de senhas. A resposta desta cadeia de lojas em Flórida foi muito mais rápida e precisa do que a do próprio Governo, envolvidos numa cadeia de decisão que começava no poder central, passava ao local e por fim às forças no terreno. A consequência foi uma resposta lenta e morosa.

Temos também os exemplos na definição de processos. Quantas empresas definem processos tão inflexíveis que perdem clientes por não conseguirem se adaptar. Um processo inflexível não abrange todas as inúmeras situações que podem acontecer num relacionamento com o cliente. Depois quando o cliente reclama a pessoa que o atende até lhe dá razão mas nada pode fazer porque por exemplo "O sistema não permite fazer isso". Temos que deixar margem de manobra para quem está no terreno, que por vezes é quem melhor compreende a circunstância e sabe como actuar.

Um pouco de filosofia

Existem duas razões para não fazermos qualquer coisa da maneira correcta.
A primeira é por desconhecimento, ou seja, a ciência não sabe explicar como fazer correctamente. A segunda é por inaptidão, ou seja, sabemos como fazer mas não o fazemos.
Há 50 anos atrás, a Humanidade podia dar-se ao luxo de não realizar correctamente seja o que for porque não sabia fazer melhor. Hoje o conhecimento é imenso. Pode parecer à partida que trata-se de uma boa noticia, mas a verdade é que este conhecimento também gera ansiedade. Gera ansiedade pelo facto de nos sentirmos culpados sempre que fugimos às boas práticas, gera ansiedade porque é virtualmente impossível realizarmos tudo, tudo como manda as boas práticas, gera ansiedade quando por vezes para realizarmos as coisas como deve ser dependemos da maturidade da nossa organização.

Hoje vivemos na era do conhecimento, e temos de saber lidar com a pressão que provém dele.

Calcular folga das tarefas com o Project

Querem saber quanto tempo podem adiar ou estender a duração de uma tarefa sem colocar em causa as datas de outras tarefas através do Microsoft Project? Usem as colunas “Start Slack” e “Finish Slack” para saberem a folga que tem para começar e terminar a tarefa respectivamente.
Tarefas no caminho critico terão valor zero nestas colunas.

Um Modelo de Maturidade de um PMO

Atendendo ao crescente estabelecimento de Project Management Offices (PMOs) nas organizações, há a necessidade de se definir claramente qual o seu papel dentro das organizações, seus objectivos, responsabilidades e a contribuição deste para um todo da organização.

Após estas definições, e à medida que o PMO se estabelece e se torna mais maduro e participativo nas actividades do dia-a-dia das organizações, há a necessidade de avaliar se as actividades realizadas pelo PMO estão alinhadas com as Melhores Práticas, assim como identificar áreas onde poderá haver melhorias que tragam mais valor para as organizações. É aqui que entra o conceito de Modelo de Maturidade de um PMO.

Tive a oportunidade de contactar com um Modelo de Maturidade de PMO, que de seguida descrevo sucintamente, e para o qual aguardo os vossos comentários.

É claro que, para que haja uma evolução nas competências de um PMO, é necessário que já exista bem definida e madura uma metodologia de gestão de projectos. A evolução da metodologia de gestão de projectos poderá ser em paralelo com a evolução das competências do PMO.

Um PMO pode ser definido com uma entidade organizacional estabelecida para auxiliar os gestores de projecto e respectivas equipas na implementação dos princípios, práticas, metodologias, ferramentas e técnicas de gestão de projectos.

O modelo de maturidade que descrevo de seguida baseia-se na publicação "The Complete Project Management Office Handbook" (Gerard M. Hill, 2004), onde as funções dos PMO podem ser divididas em cinco principais grupos de funções:

• Práticas de Gestão: define os padrões de desempenho; define processos, ferramentas e práticas de gestão de projectos, permitindo o acesso a arquivos de projectos e a uma biblioteca de referência;
  
• Gestão de Infra-Estruturas: examina o estado actual da gestão de projectos; colabora na execução de planos para o futuro estado de maturidade e apresenta as políticas e os mecanismos de controlo necessários para alcançar a competência organizacional e os objectivos propostos. Auxilia na definição da estrutura do projecto, fornece as instalações, equipamentos e colabora no envolvimento dos stakeholders necessários para apoiar o projecto.
  
• Integração de Recursos: Gere a competência, disponibilidade e desempenho dos recursos do projecto; permite ao PMO colaborar com os responsáveis funcionais para adquirir, atribuir e gerir os gestores de projecto e membros da equipa; permite ao PMO administrar a formação no ambiente de gestão de projecto e possibilitar a definição de modelos de carreira na área de gestão de projectos e apoio à equipa do project;
  
• Suporte Técnico: Fornece apoio à gestão de projectos; utiliza as competências, conhecimento e experiência dos especialistas em gestão de projecto para fornecer orientação ao planeamento; planeia e realiza auditorias aos projectos e fornece suporte adequado à recuperação do projecto;
  
• Alinhamento de Negócio: acompanha a gestão do portfólio de projectos; facilita o envolvimento dos executivos na gestão de projectos de modo a dar visibilidade das contribuições da gestão de projectos no desempenho do negócio; também gere as relações cliente/fornecedor.
  

Em termos de maturidade, neste modelo estão definidos os seguintes níveis:

• Project Office
  
• PMO Básico
  
• PMO Standard
  
• PMO Avançado
  
• Centro de Excelência
  

A identificação do nível de maturidade de um PMO depende do nível de maturidade em cada um dos cinco principais grupos de funções. É assumido que para alcançar um nível de maturidade mais elevado é necessário que tenha cumprido com todos os requisitos do nível anterior, sendo relevante referir que nem todas as organizações têm de ser "Centro de Excelência", na realidade na maioria das organizações o nível "PMO Standard" poderá ser mais do que adequado.

PMO Office:

O PMO Office caracteriza-se pelo seguinte:

• Aplica os princípios e técnicas de gestão de projecto através dos conhecimentos obtidos pelo gestor de projecto, por forma a garantir que o projecto tem um bom desempenho. O Project Office é responsável por produzir os deliverables associados aos objectivos do projecto, o que implica a análise dos objectivos e consequentemente a aplicação de medidas correctivas a problemas que sejam identificados;
  
• É a interface directa no desempenho da equipa de projecto, sendo que as equipas de projecto geralmente têm uma componente técnica elevada e o Project Office actuará como diferenciador entre os métodos técnicos e os métodos de gestão de projecto;
  
• Define as linhas de orientação sobre a forma de políticas, standards, decisões executivas, … para cada um dos projectos;
  
• É o primeiro nível de supervisão dos projectos e muitas das vezes da supervisão de alto nível do processo técnico.
  

PMO Básico:

O PMO Básico é o primeiro nível do PMO que lida com a supervisão e controlo de vários projectos. Fornece a capacidade para supervisionar e controlar vários projectos relativamente ao desempenho dos vários gestores de projecto.

Com ênfase na definição de medidas de controlo ao ambiente em que se insere a gestão de projectos, o PMO Básico desempenha um cojunto de actividades de gestão de projecto centralizada, incluindo:

• A responsabilidade primária no estabelecimento de uma abordagem padrão para gerir todos os projectos na organização, a qual inclui a definição de ferramentas comuns, processos repetitivos e práticas preferenciais;
  
• O fornecimento dos meios para apurar os resultados agregados e analisar o estado do projecto e progresso do mesmo, tornando possível avaliar o desempenho do projecto e do respectivo gestor com vista ao cumprimento dos objectivos do projecto;
  
• A gestão de projectos como uma área profissional na organização, aplicando standards, designando gestores de projecto qualificados, formando e capacitando as equipas de projecto.
  

PMO Standard:

Apesar de se manter a supervisão da gestão e controlo dos projectos, introduz-se agora o focus no apoio à optimização do desempenho individual e do projecto. O alcance do PMO Standard varia desde gestão de múltiplos projectos e múltiplos gestores de projecto até à supervisão e alinhamento com um ou vários gestores de programa.

O PMO Standard é a solução para as organizações que pretendem implementar a gestão de projecto como uma competência core ou mesmo melhorar a capacidade actual de gestão de projectos ou a maturidade associada à mesma. Exige no mínimo, em termos de recursos, um gestor de PMO a tempo inteiro e pelo menos mais dois recursos a tempo inteiro suportados por recursos qualificados com disponibilidade parcial para facilitar o desenho e implementação do PMO. Além disso, a passagem de PMO Básico para Standard pode necessitar do envolvimento de outros intervenientes nos projectos e mesmo de algumas unidades de negócio.

O PMO Standard realiza a supervisão centralizada dos gestores de projecto e actividades de controlo, com ênfase na introdução de processos e práticas para suportar a envolvente à gestão de projectos. Realiza as seguintes actividades:

• apoio à gestão de projectos, para que esta possa servir as áreas de negócio, sendo o facilitador na aplicação das práticas profissionais para gestores de projecto e membros da equipa, coordenador e colaborador nas actividades que envolvem os stakeholders do projecto (Gestores funcionais, clientes e fornecedores);
  
• Funciona como interface entre o ambiente de negócio e ambiente de gestão de projectos e traduz, sempre que apropriado, as políticas e orientações para o desempenho do projecto; também implementa as actividades associadas aos objectivos de negócio no ambiente de gestão de projectos;
  
• Actuando como facilitador no processo de definição do projecto e catalisador da excelência da gestão de projecto. Isto implica ampliar a área de intervenção na definição de práticas e metodologias para assegurar o sucesso do projecto, até à introdução de ferramentas de reporting e técnicas de colaboração para garantir o suporte a processos de governo dos projectos, gestão de portfólio e desempenho do negócio;
  
• Representa o ambiente de gestão de projectos junto da gestão de topo da organização, participando e liderando os Control Boards;
  
• Influencia directa ou indirectamente a participação dos recursos nos projectos, incluindo as abordagens a temas como a qualificação, formação, atribuição e avaliação dos recursos.
  

PMO Avançado:

Tem como focus integrar os interesses do negócio no ambiente de gestão de projectos. Implica a introdução de práticas comuns que deverão estar disponíveis quer para a gestão de projecto quer para o negócio, ou seja, o PMO Avançado auxilia a criação de estruturas organizacionais "por projecto".

A equipa de um PMO Avançado terá naturalmente de ser ampliada para incluir recursos profissionais e administrativos necessários para desenvolver, implementar e gerir os novos processos, programas e funcionalidades. O Director do PMO terá aumentado as suas responsabilidades para resolver as necessidades do negócio na área de gestão de projecto. Os recursos atribuídos ao PMO poderão estar especializados em algumas áreas de negócio específicas como forma de facilitar a integração do negócio nas práticas de gestão de projectos. O PMO Avançado executa actividades completas e compreensíveis de supervisão, controlo e suporte aliadas à expansão das funções que representam uma gestão de projectos madura e orientada ao negócio. Estas actividades incluem:

Uma vez que o PMO Avançado tem como foco a integração dos objectivos de negócio, deverá garantir que a integração dos mesmos é feita de forma eficiente e eficaz.

O Centro de Excelência:

O Centro de negócio é uma unidade de negócio independente dentro da organização e tem a responsabilidade sobre todas as operações relacionadas com a gestão de projecto.

Regra geral há um executivo responsável pelo Centro de Excelência, devendo ter acesso directo ao CEO ou a qualquer outro executivo de topo na organização. Por esse motivo, o Centro de Excelência pode ser criado dentro dos prazos associados à criação de uma nova unidade de negócios, o que geralmente se traduz a um ou dois anos para criar uma presença viável.

Apesar do Centro de Excelência ser o nível máximo de maturidade de um PMO, não significa que tenha passado necessariamente pelos níveis de maturidade anteriores. Existem duas perspectivas sobre como pode ser estabelecido o Centro de Excelência:

• Consequentemente o Centro de Excelência assume um papel de alinhamento estratégico na organização e conduz a um ambiente de gestão de projectos numa perspectiva de melhoria contínua. Resumidamente realiza as seguintes actividades:
  
• Fornece orientações e influencia a gestão de projectos da organização. pode também controlar as funções do PMO subordinado, onde a organização construiu operações relevantes em relação ao seu foco de negócios internacionais, nacionais ou focos de negócio;
  
• Constroi um ambiente de gestão de projectos, consciencializando os stakeholders da sua relevância;
  
• Patrocína e realiza estudos e avaliações das funções de gestão de projectos e eficiência empresarial, com o foco especial nas suas operações ou dos PMO's subordinados;
  
• Representa os interesses empresariais da organização na gestão de projectos e vice-versa.
  

Depois desta breve apresentação de um potencial Modelo de Maturidade de um PMO, gostaria de obter a vossa opinião sobre a utilidade da sua aplicação nas diversas organizações que conhecem e se poderia de facto trazer uma mais-valia para todos os intervenientes, nomeadamente gestores de projecto, projectos, organização, executivo de topo na organização, negócio e clientes. Outra questão é, como é que se pode apresentar/provar essas mais valias.

As galinhas e os porcos

Não se assuste caro leitor, não vou abordar nenhum tema relacionado com gripes (A H N ...), nem tão pouco relacionados com pecuária. Vou apenas dissertar sobre a grande diferença entre o comprometimento e o envolvimento.

Para introduzir o tema, vou contar uma fábula que muitos já devem conhecer:

Era uma vez, uma quinta pacata, onde existiam galinhas com as suas dificuldades e porcos com as suas ideias.

Certo dia reuniram-se todos para decidirem o que preparar para a festa de aniversário do dono da quinta. A reunião prolongou-se, conversa e mais conversa e nada se definia.

Galinha: Vamos fazer qualquer coisa, não adianta tanta preocupação! Qualquer coisa serve.

Porco: Temos de fazer a melhor festa que ele já teve, temos de o surpreender!

Galinha: Isso vai ser muito complicado, e porque vamos fazer a melhor festa para o dono se ele nem é assim tão bom para nós. Quando ele for melhor para nós, ai sim, fazemos-lhe uma festa diferente.

Porco: Se queremos que ele mude, vamos fazer melhor primeiro.

Galinha: Não vamos chegar a acordo! Vocês querem as coisas mais difíceis, temos de abreviar. Vamos começar por definir o menu. Todos concordam?

Então as galinhas sugerem.

Galinha: Vamos servir ovos com bacon?

Na historia quem está envolvido e quem está comprometido?

Os envolvidos fazem parte do grupo mas trabalham para os seus próprios objectivos. Para os comprometidos, o grupo faz parte deles e trabalham para os objectivos colectivos.

Na minha opinião, um projecto apenas tem sucesso se a maioria estiver comprometida com ele. O que origina a necessidade, ao gestor de projecto, de identificar rapidamente quem está comprometido e quem apenas está envolvido.

Recentemente, aqui no blog, foi exposto um bom exemplo de envolvimento, no post Business Case para quê?..... com uma boa proposta que pode catalisar o comprometimento dos envolvidos no Business Case com o respectivo projecto.

Este exemplo levanta a questão do comprometimento ser apenas uma questão de motivações pessoais, ou existirá alguma fórmula mágica que garanta que tudo e todos se comprometam com o projecto?

Retomando a fábula, o porco olha com serenidade para as galinhas e fala com segurança.

Porco: Se esta é a melhor solução, eu dou o meu coro, porque eu estou comprometido.

Actividades insignificantemente fatais

Quantas vezes acontece que um projecto se atrasa porque alguém se esqueceu de uma pequena actividade, quase insignificante, mas intransponível?

Recuperar dessas situações pode ser muito complicado. A responsabilidade será sempre do Gestor de Projecto (GP) pois é a ele que compete garantir a realização das actividades de forma integrada.

O problema é que estas pequenas actividades surgem no projecto (são identificadas ao GP) a propósito de uma actividade central, em situações mais informais (num telefonema, numa conversa), quase como irrelevantes. A razão para essa quase clandestinidade é que, na maioria das vezes para as equipas que as realizam, essas pequenas tarefas são pormenores, tarefas do dia-a-dia.

Prevenir estas situações exige o registo destas tarefas e o seu controlo periódico.

Para mim, não é solução ir acrescentando ao plano do projecto todas estas pequenas tarefas pela sobrecarga que exige ao fragmentarmos muito as tarefas com estes pormenores. Em vez disso, utilizo um registo de log onde identifico e caracterizo as pequenas tarefas.

Para a estrutura do registo do log considero:

· Descrição – descrição sucinta da tarefa

· DataIdentificação – data em que foi identificada

· ResponsávelExecução – Quem é responsável pela execução

· DataConclusão – Data em que a tarefa tem de estar concluída

· Estado – Estado da tarefa {Aberta, Fechada, Em Execução}

· Comentário ao estado – Observação à situação

Normalmente, uso o Excel para manter este registo. No entanto, o suporte não é importante.

Fundamental é partilhar este registo com a restante equipa de projecto.

Como resolvem esta questão? da mesma maneira?

PMI Versus Agile

Na versão tradicional de gestão de Projectos (leia-se PMI, no contexto), o âmbito do projecto é a base sobre a qual se estabelece o contrato entre um fornecedor e um cliente. Alterações ao âmbito dão origem a mudanças, que terão impacto no projecto, nas vertentes de custo, prazo, ou qualidade.
Na formulação ágil de gestão de projectos, o âmbito é essencialmente uma variável de gestão, apenas superficialmente definida, entendida como altamente mutável, sendo por isso o tempo e o custo as bases do contrato. Ou seja, num projecto Ágil, estabelece-se um orçamento, para um determinado tempo de projecto (timebox), no qual será desejável entregar um determinado âmbito, ainda não totalmente detalhado e a clarificar no detalhe, que serviu de base à estimativa de custo e de tempo. Mudanças no âmbito são assumidas ab initio como certezas, por isso a sua pré-definição não é um factor determinante do rigor da gestão.
Assim, em cada fase do projecto (sprint), é detalhado o âmbito concreto, definido o que cabe no tempo definido e negociado, em caso de necessidade, o que sai do âmbito do projecto, para continuarem a ser cumpridas as restrições do projecto: tempo e custo. O que não couber, passa para uma evolução seguinte do projecto.
Necessariamente, algumas expectativas do cliente, se não for clara esta situação, poderão ser goradas. Um produto que não cumpre, mesmo entregue no prazo, é um produto defeituoso.
Apesar das estatísticas sempre referirem que uma parte muito pequena dos projectos cumpre em prazo e em custo, será que as organizações estão verdadeiramente preparadas para aceitar que tudo é, afinal, uma questão de compromisso, resolvida pela gestão ágil?
Ou continua a ser regra que nada no âmbito é para negociar, em face das restantes restrições impostas, a não ser para cumprir o “já agora” que sempre acontece?
E como pode um GP trabalhar de duas formas tão distintas? Como muda o papel para o GP entre PMI e Agile?

Business Case para quê?

Para que serve o Business Case se não existe a posteriori a confrontação dos benefícios identificados com a realidade do Negócio após a realização do projecto?

Em muitas ocasiões, o decisor ao analisar o Business Case, só está interessado em saber se o Break-Even está dentro dos valores que possibilitem a realização do projecto. E, geralmente, não confronta os dados apresentados com a realidade do Negócio nos anos posteriores à implementação do projecto.

Por outro lado, as áreas de Negócio responsáveis pela elaboração dos Business Case, ao saberem que não irá haver confrontação dos benefícios esperados com a realidade do Negócio após a realização do projecto, sentem que podem manipular os dados do Business Case, sobrevalorizando os benefícios e subvalorizando os custos, de modo a fazerem aprovar o projecto que tanto querem, sem que sejam responsabilizados no futuro pela análise realizada.

Para que serve então, um estudo de impacto no Negócio, se as premissas não são realistas?

A confrontação do Business Case com os benefícios qualitativos e quantitativos reais para o Negócio após a realização do projecto, poderia trazer muitos benefícios:
- Possibilita a constante melhoria dos indicadores dos Business Case futuros;
- Responsabiliza as áreas de Negócio pelas análises realizadas;
- Melhora a identificação de projectos que tragam reais benefícios para o Negócio;
- Melhora o planeamento dos futuros projectos.

O Negócio só deveria fechar o dossier do projecto, quando realizasse o estudo dos benefícios reais alcançados pela sua concretização.

PMO

Muitos acham que a implementação de um PMO não é relevante na Gestão de Projectos, outros nem sabem do que se trata. A implementação de um PMO (Project Management Office) deve ser realizada em casos em que os projectos sejam extensos e complexos. Deve ser formado por profissionais que servem as necessidades da Organização em termos de Gestão de Projectos.

Um PMO desempenha diversas funções, tais como:
- fornecer suporte de Gestão de Projectos à equipa de projecto, assumindo tarefas administrativas da calendarização, produção e manutenção do repositório/histórico, de relatórios, ou outra informação do projecto, assim como a sua distribuição ou divulgação;
- desenvolver, manter e promover metodologias/normas, ferramentas e técnicas de Gestão de Projectos por forma a que as Organizações possam melhorar a nível organizacional e realizar projectos de forma consistente;
- ajudar na melhoria da rentabilidade e promover equipas de projecto produtivas.

A verdade é que muitos desconhecem a utilidade/função de um PMO numa equipa de Gestão de Projectos, mas será que depois desta breve nota vão continuar a achar a sua implementação irrelevante?

Business Case, onde começa um projecto...

Tudo começa com uma Ideia que se materializa em Business Case(BC) ou estudo de Viabilidade antes de se transformar em Projecto.

Passo a transcrever a definição de Business Case do Wikipidia:
“A business case captures the reasoning for initiating a project or task. It is often presented in a well-structured written document, but may also sometimes come in the form of a short verbal argument or presentation. The logic of the business case is that, whenever resources such as money or effort are consumed, they should be in support of a specific business need. An example could be that a software upgrade might improve system performance, but the "business case" is that better performance would improve customer satisfaction, require less task processing time, or reduce system maintenance costs. A compelling business case adequately captures both the quantifiable and unquantifiable characteristics of a proposed project.
Business cases can range from comprehensive and highly structured, as required by formal project management methodologies, to informal and brief. Information included in a formal business case could be the background of the project, the expected business benefits, the options considered (with reasons for rejecting or carrying forward each option), the expected costs of the project, a gap analysis and the expected risks. Consideration should also be given to the option of doing nothing including the costs and risks of inactivity. From this information, the justification for the project is derived. Note that it is not the job of the Project Manager to build the business case, this task is usually the responsibility of stakeholders and sponsors.”

Esta definição está correctíssima e acaba muito bem: não faz parte das funções do gestor de projecto elaborar o BC.
No entanto, não são raros os projectos aos quais foi dado o “go” sem BC ou, pior, com base num BC que não reflecte a realidade dos factos, mas o que o sponsor quer ver. Quando o projecto nos chega, já “foi dada a cara” e assumidos compromissos com cliente interno ou externo, pelo que ficamos condenados a gerir projectos mal dimensionados. A partir daí cabe-nos a nós, gestores de projectos, justificar: a necessidade de mais recursos, mais prazo, mais orçamento, o porquê de um NPV (VAL) negativo e de um payback inexistente...

Sinto uma forte resistência em envolver a gestão de projecto na elaboração do BC, tanto do parte das equipas comerciais como dos próprios PMO’s.
Os primeiros até entendo, pois a voz da razão soa como um obstáculo ao desenvolvimento do negócio. Como já ouvi uma vez: “vocês são técnicos e estão aqui para fazer das nossos mentiras verdades...”.
Que os PMO’s não queiram participar na análise de viabilidade dos projectos que irão ter que gerir, custa-me aceitar. Mas então, as lessons learned, todos os históricos de planos, de dimensionamento de equipas, de orçamentos finais, de riscos projectos... enfim, toda essa informação que o PMI tanto preza e que os PMO armazenam ,não deveria ser um dos input para o BC? Se os PMO’s são responsáveis pela gestão de portfólio, onde é que começa? O PMO não deveria querer ganhar força de intervenção na decisão de “go/no go” dos projectos?
É na Ideia e no BC que o projecto nasce, e o que nasce torto tarde ou nunca se endireita...

Datas, quero datas, e já hoje!

A quantos gestores de projecto são pedidas datas de finalização do projecto sem haver uma ideia clara do âmbito do produto?

A principal responsabilidade de um gestor de topo não é pedir datas, ainda mais quando o gestor de projecto não as tem para dar (a não ser que seja um cartomante).

O Gestor de topo deve pressionar para primeiro haver uma clarificação precisa do que se pretende do projecto, este é o passo mais importante para o sucesso, estabelecer a visão, o produto do projecto. Depois exigir planeamento, e rigoroso. E por fim as datas aparecem, e realistas.

Isto é do senso comum mas curiosamente poucos entendem este processo natural.

Penso que este aspecto está intrinsecamente relacionado com a pressão dos dias de hoje para acontecerem resultados, e por vezes essa pressa leva a saltar fases fundamentais para o sucesso de um projecto.

Ninguém pode trabalhar para resultados, podemos é trabalhar nos aspectos que potenciam os resultados. Na gestão de projecto, potenciar os resultados, i.e, o sucesso do projecto, é despender esforço em primeiro definir o âmbito do produto, e só depois planear e executar.

Parece evidente mas será assim tão comum?

Abraham Maslow nasceu a 1 Abril de 1908, faria hoje 102 anos. Defendeu uma teoria baseada na pirâmide das necessidades, hieraquizada em 5 níveis distintos, aplicável à Gestão de Recursos Humanos em todos os projectos.

- No 1º nível estão as necessidades fisiológicas, tais como as condições de trabalho em termos de ambiente físico, infraestrutura, ergonomia, horário de trabalho, etc..
- No 2º nível as necessidades de segurança, relacionadas com à continuidade do trabalho no projecto e em outros seguintes.
- No 3º nível as necessidades sociais, relacionamentos que se estabelecem com as pessoas da equipa do projecto e stakeholders, seja em termos de eventos ou comemorações por hitos alcançados.
- No 4º nível estão as necessidades de autoestima, ou seja, os elogios recebidos pelos profissionais, o reconhecimento, os prémios, bónus, etc...
- O 5º nível é o da autorealização, relacionado com a felicidade e realização por aquilo que se faz.

Ao contrário do que Maslow defendia, por vezes, as necessidades não seguem uma sequência contínua nos 5 níveis e podem sobrepor-se/misturar-se.
Mas se pensarmos num sentido mais lato, seremos movidos apenas por motivações intrínsecas, ou seja, pela vontade de realizar algo que conduza ao alcance do nível cinco?
O 4º nível poderá considerar-se a vontade externa, como um conjunto de estímulos e incentivos para levar à motivação, aos quais cada pessoa reage de maneira diferente?
Maslow afirmava que, quando uma necessidade não é satisfeita, não significará que a pessoa fica frustrada para sempre. De alguma forma, essa necessidade será compensada, pois a motivação é um ciclo constante na vida de todas as pessoas.

SPI e o Earned Schedule

Há mais de 30 anos que o Earned Value Management (EVM) tem dado uma ajuda preciosa ao Gestores de Projecto relativamente ao desempenho dos seus projectos em termos de custo e prazo, durante a execução destes. Com base nesta ferramenta, é possível tomar consciência do estado do projecto, permitindo tomar acções correctivas quando necessário, antes que este esteja quase concluído e impossibilite a sua recuperação.

Contudo, apesar do tradicional EVM ter dado uma boa resposta ao calculo das estimativas finais do custo do projecto (utilizando o Cost Performance Index - CPI), em termos de estimativas de data final do projecto já não se pode dizer o mesmo. Refiro-me em concreto ao SPI (Schedule Performance Index), indicador de desempenho de projectos em termos de prazo. Da forma como este indicador é obtido (Earned Value/Planned V alue), em que ambas variáveis são valores monetários, é dificil de acreditar que espelhe fielmente o desempenho do projecto. Há em particular 3 situações em que o SPI não fornece valores credíveis, nomeadamente quando a curva do Planned Value não é linear, quando a tarefa não se inicia na data em que está planeada e quando a tarefa/projecto acaba após a data da baseline. Neste último caso, independentemente do atraso registado, o SPI será sempre 1 (no final da tarefa/projecto tem-se EV = PV), como que indicando que a tarefa/projecto acabou exactamente no dia em que foi planeado.

Atendendo aos ponto acima referidos, com mais ênfase no último ponto, houve a necessidade de procurar uma outra forma de medir o desempenho. Há várias propostas, mas aquela que me parece mais válida é o Earned Schedule (ES), em que se pode definir como sendo o momento em que o actual EV deveria ter sido obtido. Define-se então o SPI(t) como sendo o ES/PD (Planned Duration, duração planeada da tarefa/projecto) e o tradicional SPI($)=EV/PV.

Analisemos um projecto de duração 18 meses, e estamos no mês 10. Definimos que neste mês o PV=$5M e o EV=$4M. O SPI($)=4/5=0.8. Analisando o gráfico abaixo verifica-se que o actual EV estava planeado para o mês 6 (e não no mês 10). O SPI(t) é então 6/10=0.6, ou seja completou-se no mês 10 o que estava planeado se completar no mês 6.

(figura extraída do sitio http://www.earnedschedule.com)

Consideremos agora que o projecto acabou só ao fim de 25 meses, recalculemos os SPI. SPI($)=1 e SPI(t)=18/25=0.72, valores bem diferentes. É bem notório aqui a vantagem de se utilizar o Earned Schedule para o calculo do SPI, chamado neste caso de SPI(t). É de facto mais fidedigno.

Para mais informações e detalhes sobre esta temática, aconselho a consultar http://www.earnedschedule.com/.

Na minha opinião pessoal, creio que o uso do Earned Schedule promete trazer mais rigor ao EVM e a possibilidade de se obter valores de forecast mais fiáveis. Aliás, no PMI Earned Value Management Practice Standard, versão de 2005, já inclui os principios do Earned Schedule e já o referencia com sendo uma prática emergente. É por isso conveniente estar atento/a a esta evolução na forma como a avaliação de desempenho dos projectos será feita em breve.

Negociação

Todos os projectos envolvem negociação, nem que seja de ideias. Há pouco tempo ouvi uma história que me pareceu curiosa e que aqui reproduzo:

Numa época de grande escassez de laranjas, o dono da maior produtora de laranjas foi contactado por duas empresas que pretendiam adquirir toda a sua produção. Uma delas precisava das laranjas para produzir uma vacina contra uma doença letal que punha em risco toda a população mundial. A outra queria produzir uma solução que recuperasse os danos na camada de ozono e evitasse o degelo. Não querendo desperdiçar um bem escasso, o dono da empresa convocou ambas a empresa para apresentarem os beneficios dos seus projectos. Durante dias as empresas expuseram de forma detalhada os seus argumentos e esgrimiram argumentos para defenderem a importância do seu projecto face ao da adversária. Sem conseguir tomar nenhuma decisão, o dono da empresa suspendeu as negociações e decidiu analisar os planos de produção de cada uma delas. Descobriu que para produzir a vacina apenas era o sumo da laranja e que para produzir o recuperador da camada de ozono só eram precisas as cascas.

Moral da história: para que uma negociação possa ser bem sucedida é essencial conhecer não só os seus objectivos com os da outra parte.

Sistema de Gestão de Qualidade e Gestão de Projectos

Como recentemente alguém disse e bem, desenvolver projectos em qualidade é diferente de desenvolver projectos com qualidade. Esta pequena diferença semântica, ente outras interpretações, sugere que um projecto pode ter qualidade mas não necessariamente ser eficaz e/ou eficiente. Deste modo, para garantir o alinhamento da qualidade, eficácia e eficiência é normal que as organizações implantem um Sistema de Gestão de Qualidade (SGQ), com base em ISO’s, tais como o ISO9001 (definição SGQ), ISO9000 (fundamentos e vocabulário), ISO9004 (melhoria continua), entre muitas outras normas e metodologias.

E eis que, os colaboradores de uma organização que implanta um SGQ começam a ter o sentimento de burocracia, ou mesmo de perda de tempo, em algumas das suas tarefas. E é aqui que julgo importante reforçar o objectivo de um SGQ e o seu posicionamento face à gestão de projecto. Uma compilação de normas, processos, boas práticas, metodologias… deve ajudar as pessoas da equipa de projecto a produzirem resultados mais eficazmente, eficientemente e com mais qualidade. I.e. o que garante a qualidade dos resultados são as pessoas com o suporte do SGQ, e não o contrario.

No que toca particularmente à gestão de projecto, mesmo que um SGQ defina detalhadamente variadíssimos processos para esta área, apenas uma pequena parte da actuação de um GP é contemplada, pois na minha perspectiva, gerir um projecto é também gerir pessoas, custo, tempo, âmbito, risco, satisfação do cliente, entre outros aspectos importantes para alcançar o objectivo do projecto.

E a si, caro leitor, este puzzle também lhe faz sentido?

Quem é, de onde vem, para onde vai?

Quem já geriu projectos em diferentes organizações sentiu “na pele”, quase de certeza absoluta, o que teorizam os livros: o Gestor de Projectos (GP) exerce a sua função de forma completamente diferente dependendo da organização onde está inserido.

Esta diversidade na forma como se é GP levanta, para mim, uma questão básica:

Quando é que um profissional que gere um projecto não é GP? Ou, o que tem de garantir um profissional que gere um projecto para lhe podermos chamar GP?

Na minha opinião, um GP na sua forma minimalista é:

Um profissional que consegue apresentar factualmente a situação do projecto e consegue prospectivar a situação dos trabalhos do projecto até à conclusão deste.

Concordam? Ou, saber apenas onde está e para onde vai o projecto é demasiadamente redutor para a função de GP?

Culturas

Acabado de regressar de Luanda, onde estive duas semanas, muitas das conversas acabam por cair na forma como as coisas funcionam em Angola. Não raro, as conversam giram à volta da realidade profissional, das condicionantes específicos de um país diferente, da forma como a gestão da influência se faz, como a língua simplifica ou complica a capacidade de fazer coisas e colocar todos os interessados (os stakeholders...) orientados no mesmo sentido.
É mais simples? É mais complexo? Como se consegue? que "skills" são mais importantes?
Que diferenças são visíveis entre Portugal e Angola, na gestão dos projectos?
Que importância têm os aspectos culturais na gestão de projectos, no estabelecimento de uma linguagem comum que leve uma equipa multicultural a entender-se, baseada em alguma plataforma comum de comunicação, para levar por diante um projecto?
Uma questão para debater. Porque as respostas também têm culturas subjacentes...

Relacionamento Interpessoal

Um gestor de projecto deve possuir um equilíbrio entre técnicas de gestão de projecto e competências de relacionamento interpessoal, uma vez que o trabalho de um gestor de projecto é concretizado através da equipa de projecto e de outros stakeholders. Segundo o PMI, um gestor de projecto deve possuir capacidades de liderança, team building, motivação, comunicação, influência, tomada de decisões, negociação e sensibilidade cultural e politica. Do meu ponto de vista um gestor de projecto que não possua capacidades de relacionamento interpessoal terá grandes dificuldades em concluir um projecto com sucesso pois o dia a dia de um gestor de projecto é lidar com as pessoas. Um projecto é realizado por pessoas, para pessoas com pessoas.

Faseamento vs Qualidade do Produto Implementado

Quando existe a necessidade de fasear as entradas em produção de um projecto, considerando a implementação de uma nova aplicação de TI, geralmente não se tem em consideração que o período de estabilização/garantia dos desenvolvimentos dessas fases, deve ser garantido por recursos alocados a 100% a essas tarefas de manutenção, para não afectar o plano de implementação das fases posteriores.
Normalmente, de modo a não encarecer o projecto, a equipa de implementação é a mesma que realiza a manutenção/garantia após as entradas em produção faseadas. Quando existe esta duplicação de funções, corremos diversos riscos, directamente associados à complexidade do projecto/aplicação a implementar:
- Atrasos no projecto, derivados da alocação da equipa de desenvolvimento na estabilização da aplicação em produção;
- Diminuição da qualidade dos desenvolvimentos, derivada da pressão que poderá existir se, por exemplo, parte da equipa de implementação ainda está a “corrigir” problemas da Fase 1, quando de aproxima a milestone de entrada em produção da Fase 2.

Teremos duas hipóteses, de forma a mitigar os riscos associados ao faseamento dos desenvolvimentos:

1. Identificar no plano de projecto um período de estabilização/garantia dos desenvolvimentos de cada fase, garantindo que a fase sequente só se inicia após a finalização desse período;

2. Prever/garantir a constituição da equipa de manutenção, independente da equipa de implementação, e alocar recursos dessa equipa nas fases de implementação, de modo a haver uma passagem de know-how entre as duas equipas.

Scrum

Enquanto que num projecto linear o processo de controlo de alterações exige uma análise de impacto muito exaustiva, desencorajando os pedidos de alteração de âmbito e transferindo esse esforço para a fase de planeamento, nas metodologias ágeis, nomeadamente na Scrum em que se restrição tempo é “intocável” e o custo é também muitas vezes fixo, só mesmo com alterações ao âmbito se conseguem entregas dentro do tempo e do custo.

Apesar do sucesso crescente e comprovado das metodologias ágeis na gestão de projectos de TI, não resisto a lançar duas provocações:

1. Será aceitável correr o risco de no final de um projecto se entregar um produto cujo âmbito ficou aquém do inicialmente definido para se poder cumprir com o tempo e com o custo?

2. O GP num projecto agile não se torna apenas num Gestor de Alterações, transformando-se cada Scrum num Processo de Controlo de Alterações?

Gestão Projecto

Um projecto é por definição um conjunto de actividades que, utilizando um conjunto de recursos diversos, executados num prazo de tempo limitado, permitirá alcançar um determinado objectivo.

Uma definição tão simples, a que correspondem normalmente realidades tão complexas.

Cabe-nos a nós, GP, fazer com que em cada projecto os objectivos alcançados sejam o mais próximos possível dos definidos, cumprindo com a utilização de recursos prevista.

Quem disse que a vida de um GP é fácil desengane-se, mas de uma coisa podem ter a certeza, é intensa, dinâmica e recheada de desafios que nos “alimentam” e nos dão animo para a luta do dia a dia.

Conceição Ribeiro

E surgiu um conflito...

Quem é que nunca presenciou/liderou uma reunião em que, após uma troca de ideias ou alguns argumentos, alguém não concorda e... entra em conflito? Certamente a todos.

Devem estar a lembrar-se daquela vez em que alguns dos envolvidos no projecto entraram em discórdia/conflito. Este, pode ser provocado por falhas de comunicação, incompatibilidade de objectivos, stress, ou mesmo problemas de índole pessoal, sentimentos que podem tornar as pessoas mais emotivas, podendo interferir com o trabalho.

Seja qual for a sua origem, um conflito é demasiado importante para não ser levado em consideração.

É ao gestor de projecto (ou outro líder no caso de uma reunião em que o gestor não se encontre) que cabe a redução/resolução dos conflitos.

Existem várias formas de lidar com os conflitos, dependendo da situação que os gera, tais como:

• Acomodação - para não continuar o conflito, uma parte cede, dando razão à outra;
• Supressão - quando existem temas mais importantes para discussão, ignora-se o conflito por forma a que termine por si só;
• Colaboração - quando o tema é demasiado importante e ambas as partes têm razão, saem ambas a ganhar, atingindo o cada uma o seu objectivo.

Acima de tudo, é necessário entender a o que gera um conflito para que... não se volte a repetir!

Pessoas importantes e muito ocupadas

Que fazer quando temos alguém no projecto, com grande peso (peso em termos de responsabilidade no projecto :-) ), e não tem tempo para nós? Precisamos que este tipo leia um documento com 50 páginas e sempre que estamos a falar com ele o telemóvel toca sem parar. Aqui vão algumas tácticas:

Marcar a reunião com antecedência: Se lhe propusermos uma reunião para amanhã ele vai dizer que não pode, logo a seguir perguntamos e que tal de hoje a oito? Ele vai ter mais dificuldade em dizer não duas vezes e uma reunião daqui a uma semana provavelmente não terá nada marcado. Não se esqueçam é de "obrigar" a colocar a reunião logo na agenda dele.

Um forte aliado: Se existe uma pessoa com o mesmo peso do nosso amigo ocupado, e também tem que participar na reunião, tente que seja esta pessoa a marcar a reunião.

A maneira como pedimos: Não se esqueça também que ao pedir a reunião deve passar pelos seguintes pontos:

Eu sei que tens pouco tempo e muitas responsabilidades (Estamos a compreender a situação dele)
mas preciso desta reunião senão o meu projecto incorre em mais atrasos (O nosso lado emocional)
com este documento aprovado temos os requisitos para prosseguir com o projecto que visa aplicar na prática a tua estratégia para o departamento (O que ele tem a ganhar com a reunião)
podemos marcar então a reunião para de hoje a oito às 10h para finalizar a aprovação do documento? (Mostrar claramente o que pretendemos dele)


Espero que ajude,

Bruno Fernandes

EVM, quando e como?

É uma questão que me coloco há algum tempo. Como docente de Gestão de Projecto, transmiti ao mesmo formandos a relevância do rigor do SPI, CPI e outros indicadores fornecidos pelo Earned Value Management. Como gestora de projectos na área das tecnologias de informação (TI) em empresas não TI, confesso que não consegui aplicar este método a não ser em casos que chamaria de laboratório (por terem sido experiências sem efeitos práticos para além da equipa de gestão de projecto). A venda do método EVM junto dos sponsors de projectos TI, quando as TI não são o core business, não é fácil quando implica rever/implementar processos de recolha de informação no terreno (e.g. Time-sheets ) e aumentar o peso da gestão para validação e tratamento dos dados . Na maioria dos casos, os tradicionais relatórios de progresso e controlo de orçamento servem perfeitamente. Dados os problemas de implementação que coloca o EVM, sou levada a concordar.
Será possível identificar critérios (e.g. industria, maturidade da organização, dimensão do projecto) que definam os projectos onde EVM deve ser “imposto”?

Gestão de Riscos

Um risco é um problema potencial que poderá ocorrer no futuro.
Muitos problemas podem ser antecipados e, dependendo do estado em se encontre o projecto, o gestor de projectos poderá ser mais reactivo ou pro-activo.
A gestão de risco é um processo pro-activo, que visa eliminar os problemas potenciais antes da sua ocorrência.
Alguns dos riscos comuns nos projectos são:
- Falta de comprometimento de recursos com plano e com o projecto;
- Tempo e estimativas de custos demasiado optimistas;
- Responsabilidades/funções mal definidas ou mal entendidas;
- O contributo dos stakeholders não é requerido ou as suas necessidades não estão suficientemente claras;
- Mudanças de requisitos ou novas exigências depois do projecto ter começado;
- Comunicação deficiente, originando mal entendidos, fraca qualidade ou duplicação de trabalho.
Para além da construção da matriz de probabilidade-impacto, podemos aqui partilhar experiências e mecanismos para monitorar/controlo e mitigar as consequências dos riscos.

Ferramentas de gestão de projectos

Muitas vezes, demasiadas, talvez, quando se fala em gestão de projectos, imediatamente surge em conversa o MS Project (passe a publicidade, mas a conversa tem de passar por referir os nomes).
Nada contra a ferramenta em causa, ou outras de semelhante utilidade. Já fica com sabor a pouco que a gestão de projectos com essa(s) ferramenta(s) se resuma a um Gantt Chart e pouco mais.
Por isso, e porque gerir projectos é também utilizar mecanismos e ferramentas que permitam planear, comunicar, controlar, alterar planos de projectos, envolvendo âmbito, recursos, custos, qualidade, riscos…penso ser útil falar-se aqui de ferramentas de apoio ao gestor de projecto.
Podem ser suites aplicacionais integradas, como o MS Project ou outras, que podemos aqui ajudar a caracterizar, dando dicas, colocando dúvidas, comparando, contando experiências.
Mas podem ser ferramentas simples de reporting, que permitam tirar a fotografia ao estado do projecto e com isso comunicar a todos os interessados, ou ferramentas complexas de gestão integrada de portfólio. Gostaria que este fosse, mais do que um espaço de discussão, um espaço de partilha de experiências, documentos, exemplos de boas práticas, análise de ferramentas, aprendizagem conjunta de utilização de ferramentas para simplificar a vida ao gestor de projectos.
Comprometo-me eu próprio a colocar, com algum tempo, documentos de apoio e referências que posam contribuir para o objectivo. Devo dizê-lo, vou agir sem plano.

Histórico de decisões

É muito importante mantermos um histórico de decisões do projecto actualizado pelos seguintes motivos:

1. Integramos as decisões num único repositório facilitando a sua posterior consulta;
2. Se nos confrontarem com determinada decisão, sabemos mais rapidamente quem a tomou e qual e evidência da decisão (Acta de reunião, e-mail, documento);

Sim, tal como leu é importante mantermos um controlo na evidência de decisão. Quando a decisão é tomada numa reunião ou através de um simples e-mail a evidência é fácil de provar, todavia as decisões de corredor são as mais difíceis de manter o rasto. Aconselho então, depois de qualquer decisão tomada num ambiente informal, a enviar um e-mail com a decisão tomada para a pessoa que a tomou, de forma a termos uma evidência desta. Se a pessoa não concordar com o que está escrito irá necessariamente fazer reparos. Se não responder … tal como o velho ditado diz:

“Quem cala, consente”

Um projecto não é uma ilha

Os projectos não são ilhas isoladas do mundo, e um bom gestor de projecto sabe isto. Recentemente foi-me atribuído um projecto de upgrade de um ESB (Enterprise Service BUS) numa grande empresa em Portugal. Um ESB tem por objectivo coordenar os processos de negócio que são suportados por várias aplicações tornando a comunicação mais homogénea do ponto de vista tecnológico e reduzindo a complexidade das comunicações. O problema destes sistemas é que ao fim de algum tempo tornam-se críticos, quase todos os processos vitais passam por eles. Um upgrade neste tipo de sistema tem que compreender os impactos que pode ter nos sistemas que com ele ligam e nos projectos a iniciar e a decorrer sobre ele. Gerir um projecto desta natureza sem compreender os impactos em tudo o que lhe rodeia é condenar o projecto ao fracasso. Temos que identificar projectos e aplicações que podem ser afectadas, depois identificar pessoas para as colocar no plano de comunicação e para que o plano de comunicação leve a informação necessária para que todos compreendam atempadamente os impactos que o projecto poderá ter.

A primeira mensagem

Nasce uma ideia, nasce um blog. O objectivo? Partilhar a experiência que todos nós, gestores de projecto da P&P, acumulamos ao longo dos anos a ajudar os nossos clientes a cumprir objectivos, calendários, orçamentos …. Queremos aqui boas práticas, dúvidas, referências, dificuldades, processos, templates … tudo o que toque na Gestão de Projecto. Partilhar entre nós e com o mundo na expectativa que o mundo também nos ensine a nós. Está lançado o desafio, está colocada a primeira pedra, agora precisamos de mensagens, com uma boa cadência e de grande qualidade para fazer deste blog uma peça fundamental no nosso motor de evolução profissional.