segunda-feira, março 22, 2010

Melhoria do processo de comunicação

A comunicação em projecto é dos factores decisivos para o sucesso das actividades e a obtenção de, por um lado, compromisso de gestão e, por outro, motivação da equipa e participantes.

remarEstou certo de que não é necessário convencer ninguém da importância de uma boa comunicação. As competências de comunicação são afloradas em praticamente todas as descrições de funções para qualquer posto de trabalho em qualquer nível das organizações. 

A comunicação em projecto passa por 3 fases de processo distintas: Desenho, Implementação e Gestão. Destas três, na minha opinião, devemos despender mais tempo na fase de Implementação do Processo porque é, em primeiro, a fase mais subestimada e, em segundo, porque é aquela em que é mais fácil serem introduzidos erros.

Em outras ocasiões, tenho sublinhado a importância de, em gestão de projecto como em outras áreas, ser desenvolvida a evidência de gestão da mudança organizacional com saliência para os seus dois componentes principais: Comunicação e Formação.

Sublinho sempre que a Comunicação é muito mais do que “enviar emails” e, por isso, insisto em que a comunicação é muito mais do que uma comunicação de «dois sentidos». Porque não, então, um modelo de comunicação assente em «4 fases»? E quais são elas:

1. Dizer / enviar a mensagem

2. Validar que a mensagem foi recebida.

3. Validar que a mensagem foi compreendida.

4. Validar que a mensagem foi aceite.

Não é suficiente só dizer ou enviar a mensagem e então assumir, bem assumir tudo. O remetente deve realizar os passos que lhe garantem que a mensagem foi mesmo recebida. E, mesmo se a mensagem foi recebida, pode ser necessário que seja compreendida. Finalmente, mesmo de a mensagem é compreendida, pode haver mal entendidos evitando que a mensagem seja, de facto, aceite.

A comunicação não pode ficar baseada em assumpções. A comunicação deve ser validada e isso exige algum trabalho e seguimento.

Embora seja provável que perceba porque não sugiro estas tácticas para a minha cara-metade, julgo que esta é uma abordagem razoável no dia-a-dia dos negócios. Penso, ainda, que é óptimo modelo para os gestores de projecto, que provavelmente dependem da comunicação mais do que quaisquer outros.

A comunicação é, hoje, essencial em todos os aspectos do sucesso das empresas, e está em questão muito mais do que só uma chávena de café.

Luís Quintino

quinta-feira, março 18, 2010

O que é a WBS?

 

Esta coisa da Gestão de Projectos de que toda a gente acha que sabe alguma coisa, senão tudo, e que é reduzida à expressão «isso é feito com o Project», como se um programa de computador fosse equivalente a uma metodologia de conhecimento, é muito mais complexa. No nosso mercado, estes conhecimentos têm muitas lacunas e mesmo o completo desconhecimento quando se trata de ferramentas de pensamento essenciais para planear de forma adequada. Hoje vamos tentar responder à pergunta o que é a WBS?

IMG00413Uma WBS (Work Breakdown Structure) ou Estrutura de Decomposição do Trabalho representa de forma consistente as actividades de topo requeridas para concluir o projecto. O foco desta WBS pode ser quer o Produto (resultado) quer o projecto, ou ambos. Os elementos da WBS são numerados usualmente e este sistema de numeração pode ser organizado de diferentes formas. O propósito primário de uma WBS é desenvolver ou criar conjuntos pequenos e geríveis de trabalho denominados Work Packages.

Assim a WBS

  • Serve como plano base do âmbito do projecto
  • É uma das mais importantes ferramentas de gestão de projecto
  • Está na base do planeamento, estimação e controlo do projecto
  • Permite visualizar todo o projecto
  • Sublinha que trabalho NÃO incluído na WBS NÃO faz parte do projecto
  • Reforça a adesão da equipa ao projecto
  • Serve de mecanismo de controlo para manter o projecto na data prevista
  • Permite estimativas mais exactas de custo e tempo
  • Serve de redutor do derrapar do âmbito do projecto

A WBS não deve ser confundida com::

  • A OBS ou Estrutura de Decomposição Organizacional
  • Lista de Materiais
  • Estrutura de Decomposição do Risco
  • Structure de Decomposição dos Recursos

Esta ferramenta está relacionada directamente com o agendamento de um projecto. No fundo, é uma decomposição funcional das actividades de um projecto, em que o trabalho total do projecto é sucessivamente decomposto em subtarefas. Começa pelo objectivo final a atingir e requerido e sucessivamente subdividindo em componentes geríveis em termos de dimensão e complexidade, desta forma por exemplo: programa, projecto, sistema, subsistema, componentes, actividades, sub-actividades e elementos de trabalho.

Dicionário da WBS

Quando a WBS construída é extensa ou se as categorias do seu conteúdo não são óbvias, para os membros da equipa de projecto, pode ser útil escrever um Dicionário da WBS. Este documento irá descrever cada elemento da WBS e pode ainda dizer o que não é um elemento.

Os benefícios de utilizar uma WBS são:

  • Reforço da equipa de projecto em torno de um mapa único do trabalho
  • Oferece uma estrutura para identificar os projectos separadamente das organizações, sistemas de custos, fontes de financiamento
  • Clarifica as responsabilidades
  • Concentra o foco do projecto nos seus objectivos
  • Força um planeamento detalhado e a respectiva documentação
  • Identifica Work Packages específicos para a respectiva estimação e alocação de trabalho.

A Work Breakdown Structure (WBS) é um ponto central no esforço de planeamento do projecto. Não é possível desenvolver um realístico plano para um projecto sem primeiro se desenvolver uma WBS que será detalhada o suficiente para permitir uma significativa identificação de todas as actividades do projecto que devem ser concluídas. O processo de criação de uma WBS é muito importante, porque durante este processo de decomposição do projecto, o gestor do projecto e a equipa, bem como todos os gestores funcionais envolvidos são forçados a pensar acerca de todos os aspectos do projecto.

Resultados específicos da WBS

Uma WBS é uma técnica de decomposição de um projecto nos seus elementos constituintes. As actividades mais pequenas, denominadas Work Packages, devem ser identificadas como unidades geríveis que podem ser planeadas, orçamentadas, agendadas e controladas. A WBS indica a relação entre a estrutura organizacional e os objectivos do projecto e as suas unidades e dessa forma oferece uma base firme para planear e controlar o projecto.

A WBS deve ser orientada ao produto ou orientada à actividadem e deverá incluir todo o esforço necessário, que deve ser levado a cabo para atingir o objectivo final. Porque ela identifica o trabalho exigido para alcançar um objectivo ela ajuda a identificar os interfaces necessários e desta forma é muito útil em projectos complexos. Contudo, tem uma limitação importante, ela não mostra o tempo das actividades o que implica a utilização de outras ferramentas.

Luís Quintino

terça-feira, março 16, 2010

Processos que apoiam o sucesso em projecto (Parte 2)

Na semana passada vimos que, apesar de estar convencido que os fracassos em projectos resultam de pobre Gestão de Projecto e Portfólio – ou mesmo a total ausência desses processos, há um conjunto de coisas que podem ser feitas para melhorar as oportunidades de sucesso. Falámos então do papel do Sponsor do projecto e da melhoria na Definição do Projecto.

Hoje continuamos com:

Desatenção ao Processo de Mudança do Negócio

Esta é a raiz de muitos fracassos em projecto, designadamente na área das TI. O foco de muitos projectos é muitas vezes colocado na transformação tecnológica e é dada muito pouca atenção ao impacto da mudança e à necessidade de acompanhar esta como um processo de negócio. O Gestor de Projecto consegue criar as novas funcionalidades mas o valor e os benefícios não são muitas vezes compreendidos e, em virtude disso, demoram a ser usados. IMG00491

As alterações de processos de negócio necessitam de uma compreensão e execução de gestão de processo e de gestão organizacional, que são disciplinas essenciais à transformação do comportamento humano. A Fase de Definição do Projecto deve determinar se estas mudanças de processos de negócio se localizam dentro ou fora do âmbito do projecto.

Desconhecer qual o Factor de Sucesso que é mais importante: Tempo, Custo ou Performance.

Como já vimos, as razões directas de fracasso dos projectos são diversas. O projecto pode estar atrasado, acima do orçamento e abaixo na performance. Na gestão de projecto costuma dizer-se: custo, tempo ou performance, escolha uma de duas. Os gestores de projecto devem saber qual destes Factores de Sucesso do Projecto é mais crítico. O Sponsor do Projecto deve trabalhar com a Administração para atingir um consenso sobre a máxima prioridade e gerir o projecto em conformidade.

Pobre comunicação

A comunicação pobre é uma fraqueza dos projectos. Todos os Gestores de Projecto devem desenvolver e manter um Plano de Comunicação de Projecto formal, bem pensado e completo. Um gestor de projecto deve saber quem necessita de que informação e quando e como será essa informação fornecida. Isto exige aos Gestores de Projecto não só que compreendam as decisões exigidas para governar os projectos até à sua conclusão com sucesso, mas também devem mapear estas decisões aos dados requeridos para garantir que estas são correctas e racionais. A outra dimensão para ultrapassar as pobres comunicações é a necessidade essencial para os Gestores de Projecto para fornecerem dados exactos, tão rápido quanto possível. Procedendo desta forma, os Gestores de Projecto devem evitar, ou melhor ultrapassar, qualquer impulso para esconder más notícias ou diminuir riscos ou problemas.

Processo ou Metodologia impróprios

Alguns Projectos falham tão só porque não possuem um processo e metodologia adequada de gestão de projecto. Isto não ocorre unicamente quando não é aplicada nenhuma metodologia, Os fracassos podem também ocorrer quando são impostos demasiados processos à equipa de projecto. Os gestores de projecto devem possuir uma compreensão elevada sobre processos e metodologias provadas na prática. Esta compreensão é essencial para aplicar o «tempero» correcto de metodologia de gestão de projecto e para lutar pela manutenção do equilíbrio delicado entre demasiado ou pouco processo.

O que acha? Julga que tratei destas questões mais gerais dos factores que contribuem para o fracasso dos projectos? Julga que há mais? Quais?

sábado, março 13, 2010

Processos que apoiam o sucesso em projecto

Recentemente numa sessão de formação em Gestão de Projecto um participante levantou o problema do insucesso em projecto sugerindo a necessidade de aprofundamento do estudo das principais causas objectivas desse facto. Os fracassos assentam em erros, mas eu acredito que estes fracassos nos projectos resultam de pobre Gestão de Projecto e Portfólio – ou mesmo a total ausência desses processos.

Há, entretanto, algumas coisas que podem ser feitas para melhorar de forma drástica as oportunidades de sucesso dos projectos.

Sponsor do Projecto

A maioria dos projectos são hoje encomendas que são acompanhadas pelos clientes através da nomeação de um responsável – o sponsor.

A falta de empenhamento apropriado do Sponsor do Projecto pode destruir qualquer projecto. Para além de fornecer a potência que permite ultrapassar as questões e riscos que ameaçam inevitavelmente todos os projectos, os Sponsors do Projecto oferecem uma ligação directa com a Liderança e Estratégia Corporativa.

Estudos recentes comprovam que quanto mais eficaz for esta ligação à estratégia de negócio mais eficaz será o progresso. Ao contrário, uma ligação quanto mais ténue for a ligação entre o projecto e a estratégia, mais desafios serão encontrados pelo projecto. Os Sponsors devem ainda assumir o controlo de performance do projecto para garantir que este se mantenha no curso certo para cumprir os objectivos da estratégia – monitorizando simultaneamente a performance de projecto e a direcção estratégia corporativa (que pode ser mudada durante o decurso do projecto).

Definição pobre do projecto

Os projectos mal pensardefinidos estão amaldiçoados à partida. É imperativo que todos os projectos possuam objectivos de negócio e técnicos concretos e uma compreensão exacta e descrição do que se vai realizar com eles. Nada garante melhor que os projectos são correctamente definidos do que o cumprimento de um confiável processo de caso de negócio do projecto – em Portugal seria denominado um estudo de viabilidade – e um processo de definição de charter do projecto (o mapa das estradas para guiar o projecto) para ser seguido «religiosamente» por todos os envolvidos.

Este Caso de Negócio do projecto confiável fornecerá os dados necessários para determinar não só se o projecto deverá ser realizado mas também se poderá ser feito. Logo que aprovado este Caso de Negócio um compreensivo Charter do Projecto irá descrever o Quem, Quê, Onde e Quando do projecto. Então o que deverá ser incluído neste Caso de Negócio? Algumas sugestões de elementos frequentemente não incluídos ou não respondidos nos casos de negócio, como:

Os benefícios de negócio que são alvo e o seu alinhamento com a estratégia de negócio – quem do negócio ficará responsável por os garantir.

  • As mudanças no negócio necessárias para criar um valor adicional
  • Os investimentos necessários para fazer as mudanças de negócio
  • Os investimentos requeridos para mudar e adicionar novos serviços, bens ou produtos
  • Os custos de negócio para operar da forma alterada
  • Os riscos inerentes em todos os referidos acima incluindo quaisquer constrangimentos ou dependências
  • Quem terá de prestar contas pela criação com sucesso do novo valor óptimo
  • Como serão monitorizados o investimento e a criação de valor através de todo o seu ciclo económico e quais as métricas utilizadas.

(Elementos retirados do Business Case da Val IT Framework)

(continua)

quinta-feira, março 11, 2010

Gestão dos Problemas da Equipa

Bloqueio e negação estão entre os problemas mais comuns em muitos projectos.

Estes fenómenos relacionam-se com os graus insuficientes de bloqueioconsenso entre os participantes numa equipa de projecto. Esta falta de comunicação, já que é disso que se trata, é um dos maiores obstáculos ao sucesso.

Sem um consenso suficiente em questões importantes de projecto ocorrem muitas vezes dois problemas:

  • Bloqueio: o progresso do projecto pára, por falta de consenso ou acordo nos melhores passos para avançar. Em situações de bloqueio, a equipa não alcança um acordo e as decisões de projecto tornam-se lentas ao mesmo tempo que todos discutem.
  • Negação: O progresso do projecto continua, apesar da falta de consenso. Em situações de negação a equipa não enfrenta as divergências, acordando em aguardar até, em qualquer momento no futuro, resolver os problemas em aberto. Os problemas então escondem-se só para depois «inesperadamente» irromperem mais tarde, usualmente numa forma mais severa.

Face à incapacidade de obter o acordo da equipa aqueles que devem tomar as decisões ficam com poucas escolhas a não ser aceitar os atrasos do projecto no presente, ou ignorar os problemas diferindo as soluções para o futuro. Estas atitudes tornam-se assim as causas de muitos fracassos em projecto.

Estes problemas de comunicação minam o nível saudável de colaboração que a equipa deve possuir e conduzem a falhanços. Não há uma fórmula mágica para resolver e4stes problemas, que estão profundamente enraizados na cultura e hábitos da forma como as equipas trabalham em conjunto.

Dito isto, sugiro criar uma atitude atenta e cuidadosa às reuniões da equipa em que se apresentem questões de difícil consenso. Para agir sobre as questões, procure um caminho que faça agregar os propósitos e expectativas dos participantes do projecto. Esta opção pode envolver reuniões privadas, discussões de grupo ou talvez até uma combinação de poções mágicas e muita sorte. Independentemente do método utilizado é crucial a demonstração das expectativas dos departamentos ou silos de informação.

Não há nenhuma organização que esteja imune ao bloqueio e negação. O reconhecimento deste facto oferece uma oportunidade realista de interromper os ciclos disfuncionais de colaboração que podem estar escondidos entre as «brumas» da familiaridade na participação da equipa.

Conhecer o problema é já o início da solução.

quinta-feira, março 04, 2010

Porque não deve ir para a Gestão de Projectos?

 

Continuação. Tratámos antes das características que se relacionam mais com as capacidades de comunicação das pessoas que estão ou querem ir para Gestor de Projectos, mas que talvez não preencham mesmo as condições indispensáveis.

Ho je tratamos das preferências e gostos. Ora vejamos:

#5: Não gosta de cumprir processos

Sim, eu sei que ninguém quer ser escravo dos processos. Mas são precisos bons processos para ser efectivo, ao mesmo tempo que os seus projectos se tornam maiores. Se não quer seguir bons processos de gestão de projecto, você não vai conseguir ir longe como gestor.

#6: Você não gosta de documentar as coisas

Claro, fazer tudo com moderação. Eu não estou a propor que deva adorar documentar para ser um bom gestor de projecto. Mas também, pelo contrário, não pode odiar isso. Muitos aspectos da gestão de projecto exigem alguma documentação, incluindo os relatórios de status, planos de comunicação, alterações de âmbito e Charters de projecto. caras

#7: Você gosta de executar e não de planear

Quando um cliente lhe adjudica um projecto, qual é a sua primeira inclinação? Se o seu primeiro pensamento ´0e reunir uma equipa e executar o trabalho, provavelmente não tem uma estrutura de pensamento de um gestor de projecto. Se não quer gastar uma apropriada quantidade de tempo para se assegurar que compreendeu o que deve ser feito, provavelmente não está talhado para ser um gestor de projecto.

#8: Se prefere receber ordens

Se pensa que o seu trabalho é receber ordens do cliente e executá-las, pode não ser um bom gestor de projecto. Os gestores de projecto devem oferecer valor para o projecto, incluindo resistindo quando os clientes pedem coisas que não estão correctas. Se o cliente levanta um pedido que está for a do âmbito, você deve ter também de invocar o processo de gestão da mudança de âmbito. «Sim senhor, iremos fazer isso» em vez de passar pelo processo de gestão da mudança de âmbito, tornará gerir o projecto uma luta para si.

#9: Você não é organizado

Pessoas que têm pobres capacidades e técnicas de organização pessoal não dão bons gestores de projecto. Se vai gerir múltiplas pessoas ao longo de um período de tempo, deve ser bem organizado para garantir que todos e cada um está á fazer o que ele ou ela precisam de fazer para serem os mais eficientes possíveis.

#10: Se pensa que a gestão de projecto é um «peso»

Ninguém consegue sentir-se bem acerca do seu trabalho se pensa que o que realiza não adiciona valor. Os bons gestores de projecto compreendem o valor do seu trabalho, e percebem que do seu trabalho irá resultar no projecto e fará que ele seja realizado em tempo e dentro do orçamento, com uma boa experiência para o cliente e para a equipa. Se pensa que os trabalhos associados com a gestão do projecto são um peso e não um valor.

Agora pense. Se está incluído em mais do que 3 destas condições, já deve reflectir se vale mesmo a pena e se estiver em 5 ou mais fuja…

segunda-feira, março 01, 2010

Porque não deve ir para a Gestão de Projecto?

 

Muitas pessoas têm alguns traços para serem um bom gestor de projecto, mas também têm muitos que o fazem considerar ser mau para essa posição. Coleccionei uma lista de indicações que mostram que podem não estar bem preparados para ser um gestor de projecto. Repare que estas notas não têm nenhuma hierarquização.

#1: Você é um comunicador pobre

Diz-se que mais de 50% do tempo de um gestor de projecto é dispendido em algum aspecto de comunicação. Isto inclui reuniões, relatórios de status, emails, chamadas telefónicas, coordenação, falar com pessoas e completar documentação. Alguns estudos mostraram que a comunicação verbal e escrita ocupa 80% da função. Se você não é um comunicador efectivo (e você não procura sê-lo) então não siga por este caminho.

#2: Você não consegue trabalhar bem com outras  pessoasequipa

Prefere ficar no escritório e focar-se no seu próprio trabalho, provavelmente não possui uma capacidade colaborativa para ser um bom gestor de projecto. Bons gestores de projecto devem gastar muito tempo com clientes, stakeholders, e membros da equipa.

#3: Você prefere os detalhes

Muitas pessoas gostam de trabalhar nos detalhes do projecto. Necessitamos sempre de dispor de pessoas destas. Mas quando se é gestor de projecto, devemo-nos erguer acima dos detalhes e tornarmo-nos mais como quem delega e como quem coordena. Precisamos de confiar em outros, quando se desempenha a função de gestor de projecto, para que façam uma grande parte do trabalho detalhado .

#4: Não gosta de gerir pessoas

Não há muito de um projecto se você for o único recurso. Se quer ser um bom gestor de projecto deve ser capaz de gerir pessoas. Não terá 100% da responsabilidade sobre as pessoas, mas terá de mostrar liderança, torná-los responsáveis e aptos a prestarem contas, gerir conflitos, etc. Alguns gestores de projecto dizem que poderiam realizar um trabalho muito melhor se não tivessem de se relacionar com pessoas. Se é isso que sente então a gestão de projecto provavelmente não é para si.

Mas há mais! Leia na próxima semana.