Revista BEWARE - Agosto 2012

Estatísticas do Gerenciamento de Projetos – Gerenciamento de Tempo

Em pesquisa realizada em 2011, com 202 projetos no Brasil, foi constatado que cerca de 20% dos projetos não elaboraram o Cronograma e que 40% acharam que o nível de detalhamento das atividades do cronograma não foi condizente com o nível de controle requerido para o projeto. O fato de 44% não alocarem recursos às atividades para a definição do esforço / duração mostra que não levaram em conta os recursos para as estimativas de tempo. Também se verificou que as técnicas de nivelamento de recursos e da cadeia crítica só foram utilizadas por cerca de 20% dos projetos.

Que práticas listadas abaixo foram aplicadas na elaboração do cronograma?	%
As durações das atividades / tarefas foram estabelecidas	78,7
As dependências entre atividades / tarefas foram estabelecidas	77,2
O cronograma foi elaborado a partir da Estrutura Analítica do Projeto	60,4
O nível de detalhamento das atividades do cronograma foi condizente com o nível de controle requerido para o projeto	58,4
Os recursos foram alocados às atividades / tarefas para a definição do esforço / duração das atividades / tarefas	56,4
O método do nivelamento de recursos foi utilizado para o desenvolvimento do cronograma	23,3
O método da cadeia crítica foi utilizado para desenvolvimento do cronograma	20,8
Nenhuma das práticas acima foi aplicada no projeto	5,9

Cerca de metade dos projetos não utilizou informações históricas nem o calendário dos recursos para a estimativa de tempo, o que mostra a fragilidade das estimativas realizadas. A estimativa de três pontos não foi utilizada nem por 20% dos projetos.

Que práticas listadas abaixo foram aplicadas na definição das estimativas de tempo e recursos (pessoas, equipamentos e materiais) do Projeto	%
O Calendário do Projeto foi definido	67,8
Os Calendários dos recursos foram definidos	50
Foram utilizadas informações históricas para auxílio de estimativas de tempo	50
Foram utilizadas informações históricas para auxílio de estimativas de recursos	47,5
Foi utilizada a estimativa de três pontos para o planejamento do esforço e/ou duração das atividades do projeto	17,3
Nenhuma das práticas acima foi aplicada	7,4

Em relação aos resultados do gerenciamento de prazo, foi verificado que uma menor parcela dos projetos (26%) obteve ótimos resultados em relação a prazo, e que cerca de 40% tiveram um desvio acima de 25% em relação à base de referência.

Qual foi o resultado do gerenciamento de prazo do projeto em relação ao último baseline?	%
Menor que 0,74 ou maior que 1,26	38,7
0,75 a 09,4 ou 1,06 a 1,25	35,2
0,95 a 1,05	26,1

Isso mostra que existe muito a melhorar em relação ao gerenciamento do tempo de projetos.

Fonte: Draft da Tese de Doutorado de Carlos Magno da Silva Xavier (M.Sc., PMP)

Visão de Ética (PMI)

Establish a worldwide network of project management professionals and connect them via this community platform.

Train practitioners via webinars, discussion forums, and articles for enhancing member skills.

Host a technology-based virtual environment to exchange experiences, ideas, and solutions in the area of Ethics.

Interact and explore opportunities to formalize relationships with other Business Ethics Organizations.

Communicate with membership and encourage involvement as Thought Leaders and Contributors.

Share documents, articles, news, and presentations.






Fonte: Ethics in Project Management Community of Practice.

Fighting Project Manager Stereotypes

PMI Community Post

--------------------------------------------------------------------------------------------------

Fellow project managers: Who are we?

Are we the paper pushers and process police, as an article in this month's PM Network® magazine is titled?

Do we really obsess over reports, come across as control freaks or do everything "by the book"?

Even though most project managers deny they fit these stereotypes, perception is reality for your stakeholders and team members. You may have to fight these false perceptions. Or maybe you need to examine your attitude.

Fight Back!
Do your team members or stakeholders really feel they are drowning in reports? Work with your organization to see if it´s possible to minimize the volume of project documentation.

Then, clearly communicate the importance of basic reports for the project, particularly for monitoring and controlling, risk management or future lessons learned.

Project managers who are seen as controlling should contemplate a change in attitude. Consider adopting a "servant leader" mentality. Try to transfer your responsibility from making decisions for the team to coaching them so that they can make their own decisions.

Project managers always need to be open to new ideas. Ideas about these new ways of working may come from books, journals, your team or other project managers. Creativity should always be part of the equation—and that can help fight a project manager’s "straight-laced" reputation.

How Your Organization Can Help
Organization executives and project managers themselves can do their part to put to rest any misconceptions about their project managers.

Education of stakeholders and team members will help—perhaps you, as the project manager, could initiate that. Additionally, professional and personal development can assist project managers who might see a little truth in their labels.

Everyone Stereotypes
Of course, stereotypes can go both ways. Software developer Kenneth Ahlstrom posted a 3 x 3 matrix on hisblog that, somewhat tongue in cheek, noted that project managers might view developers as "unthinking assembly-line workers," designers as "unthinking assembly-line slave workers with paintbrushes" and themselves as "leaders of the free world with all of the ideas and know-how."

Mr. Ahlstrom had a remedy for all this labeling: Understand your own role and respect the roles of others. "Resentment sets in when one group or another attempts to infringe on another group's job."

Guido Schoonheim, CTO at Xebia, an IT services firm based in The Netherlands, advised project managers to "Provide structure and process while promoting personal initiative. Deliver on time and budget while keeping your team happy and healthy. It is your job to find the appropriate balance between these forces and thereby avoid these stereotypes."

Mr. Ahlstrom concluded that if everyone learns to "trust, respect and value each other, the stereotypes... will continue to fade and our projects together will reach heights never before imagined."

Is this you?

Blogger Kailash Awati, co-author of The Heretics Guide to Best Practices, presents these project manager caricatures:

Barry Bureaucrat: Barry has a form for everything and is a master of fine print.
Conroy Cowboy: Con has a strictly shoot-from-the-hip approach. He reacts fast to events, even if that means there's no thought preceding the action.
Igor Inflexible: Once he has an opinion, he's congenitally incapable of changing it.
Mac Machiavelli: Mac's a schemer. To him, the project and team are important only in how they serve his relentless pursuit of fame and glory.
Norman No–decision: Norm enjoys discussing issues and analyzing them. He’s elevated analysis paralysis to a fine art.
Sally Shifter: Sally has an unblemished record as a project manager because she's good at shifting the blame for mess-ups on to other people, generally her team members.

Do you deal with these people?
Mr. Awati also wants you to know what stakeholders look like:

Andrew Astronaut: With all the big-picture stuff to look after, your project is just a small speck of inconsequence for him.
Charlie Count-the-cash: Charlie sees the project as a black hole for company cash. To counter this, he has a bag of tried and tested money-saving devices.
Devlin Details: He's the kind of sponsor for whom the 50-page progress report (and the 500-page business case) was invented.
Len Leftfield: Len's questions may not be relevant, but they're always clever and, of course, unanswerable.
Mick Micromanager: Mick likes to see the "small picture" or the "trees for the forest," and offer unsolicited advice on project planning and execution.

"Stereotypical behavior generally occurs in dysfunctional environments where stakeholders assume adversarial attitudes that lead to conflict rather than cooperation," said Mr. Awati. "The key to avoiding such problems is to reconcile diverse viewpoints upfront so that all stakeholders have a shared understanding of project goals and a shared commitment to achieving them."

Uma semana de 4 dias

Seis motivos para considerar a redução da jornada de trabalho em um dia, enquanto aumenta exponencialmente o moral da empresa.

By Jay Love |  @SlingshotSEO   | Jan 11, 2012

Depois de viver dentro dos limites de uma semana de trabalho de quatro dias durante os últimos quatro meses em Slingshot SEO, minha primeira reação a questões sobre este privilégio inacreditável é "Por que não?" Proprietários de pequenas empresas, CEO e executivos de todo o país perguntam-me em uma base semanal, se ele realmente funciona. Minha resposta é um sonoro SIM!
Obviamente, se você tem um grande componente de serviço ao cliente para seu negócio ou se deve ser aberta por horas de varejo, é preciso um pouco de ingenuidade e algumas proezas agendamento para ajustar a este tipo de programação. Talvez depois de ler este post no blog você vai querer experimentar uma versão piloto do famoso Slingshot SEO quatro dias-semana de trabalho em seu negócio. Se fizer isso, eu gostaria de saber como ele vai ou responder a uma pergunta ou duas.
Primeiro, deixe-me explicar o "porquê" por trás desse conceito, começando com um aspecto muito importante da parte "pessoa" de qualquer negócio: a "Cultura da Empresa" acredite ou não, muitos aspectos da nossa cultura estão diretamente relacionados a este privilégio especial. Aqui estão algumas das razões para essa afirmação e, talvez, algumas perguntas que você deve perguntar-se como um empresário:

1- Quanto mais inovador e emocionante seu negócio seria se cada membro da equipe passasse  um dia inteiro a cada semana dedicada à investigação? Quais insights, novas idéias e energias seria bombeadas para o seu negócio?

2- Como um benefício, é um elemento surpreendente para o recrutamento dos melhores talentos para sua equipe. Como uma música de sucesso, o seu departamento de RH precisa de um "gancho" para reter os melhores funcionários. Isto vaifazer uma diferença incrível!

3- Em consequência ao item 2, a sua taxa de retenção de funcionários, literalmente, voa! Quem iria querer desistir de três dias em casa, só computando quatro dias de trabalho por semana e o exercício cerebral da pesquisa semanal?

4- Mesmo que a equipe esteja trabalhando 10 horas por dia, o senso de urgência traz um alto nível de energia, e, na minha opinião, com foco colaboração. É uma alegria para assistir e ser sugado para dentro da equipe de solução.

5- O tempo extra para a pesquisa contribui para o desenvolvimento de uma equipe bem informada e a unicamente realizada. (Além disso, uma reunião reparadora numa sexta-feira em um planejamento numerosas escapadas de três dias getaways nunca seria negada...)

6- No nosso caso, as noites de quinta, depois do trabalho, se tornaram uma oportunidade ainda maior para a socialização da equipe e diversão. Isto também parece ser vital para as taxas de retenção dos profissionaos. Um estudo recente indicou que a primeira razão para uma pessoa não mudar de emprego é baseada em ter um amigo na mesma empresa. Parece fazer sentido, certo?

Adicionar estas seis razões, junto a três ou quatro que você provavelmente se lembrou ao ler este blog e você deve chegar à conclusão de que o foco extra, energia, trabalho em equipe e dedicação resultante de uma semana de trabalho de quatro dias vai levar a sua produtividade para o céu! Não é um resultado ruim para uma idéia simples ...

http://www.linkedin.com/news?actionBar=&articleID=5562842806801670153&ids=0PczcMe38OcjwNdjANe3sPdzkRb3cVdPkVcPwUdzkMcP8Rc3gSdjkIcP8PcjgVc3oMdzgMc3kTczoRdiMNc3wMdjkOdz4Oe3AMejAOdzkRb3gPd3wRc3ARdP8Rej8VdP8SdjkIcj8Td3gRej0UdzoOc3AQczoRdiMPdj4MdPoNc3wSc3wOd3wOdzkR&aag=true&freq=weekly&trk=eml-tod2-b-ttl-0&ut=2S0J1aG3y6pB41

Os provérbios mais famosos do mundo de projetos

15 - Congelamento de requisitos e o abominável homem das neves são parecidos – ambos são mitos e ambos se derretem quando o calor apropriado é aplicado.

14 - As condições sob as quais uma promessa é feita são esquecidas, porém, a promessa será sempre lembrada.

13 - Um usuário somente lhe falará o que lhe for perguntado – nada mais.

  

12 - A  primeira coisa para um projeto dar certo é que os stakeholders queiram que dê certo.

11 - Diante de varias interpretações de um comunicado, a menos conveniente é a mais correta.

10 - Quanto mais desesperada a situação, mais otimista ela é.

09 - Poucas pessoas conseguem resolver os problemas em um projeto, porém muito mais pessoas criam problemas acima da capacidade das primeiras resolverem.

08 - Você pode congelar os requisitos de um sistema, porém não consegue congelar as expectativas dos usuários.

07 - Não existe almoço grátis – se alguém te ofereceu um, você com certeza vai pagá-lo.

  

06 - Congelamento de requisitos e o abominável homem das neves são parecidos – ambos são mitos e ambos se derretem quando o calor apropriado é aplicado.

05 - Você não consegue fazer um bebê em um mês usando nove mulheres.

04 - O mesmo trabalho será estimado de forma diferente por 10 analistas ou por um mesmo analista em 10 diferentes vezes.

03 - A palavra mais útil e menos usada no gerenciamento de projetos é "NÃO".

02 - Você pode convencer um alguém a assumir um prazo irreal, porém, você não pode obrigá-lo a cumpri-lo.

01 - Quanto mais ridículo o prazo, mais caro e difícil será cumpri-lo.

Vinte erros mais comuns (Parte IV)

(última parte da publicação)



ERRO # 16: Mostrar a todos "quem é que manda"
Muitas vezes um gerente de projeto se vê como o "presidente" do projeto. Por um lado isso não é necessariamente ruim, embora os gerentes de projeto devessem ter a percepção que o nome do cargo é apenas um título e com pouca autoridade real. O gerenciamento de projetos é frequentemente descrito como a liderança sem autoridade.
Um gerente de projeto que tenta mostrar que ele tem total poder sobre o projeto pode alienar os membros da equipe, especialmente aqueles que entendem alguma coisa de gestão de projectos. Às vezes, os membros da equipe deixarão o gerente do projeto acreditam que ele tem a autoridade e, em seguida, o usarão para descarregar toda e qualquer decisão do projeto, lançando sobre o gerente toda a responsabilidade por uma possível decisão equivocada.


ERRO # 17: Não se interessa em conhecer sua equipe
Pessoas que trabalham em equipes de projeto, principalmente se organizadas em uma estrutura matricial, sabem que têm um retorno garantido para a sua área funcional original depois que o projeto for concluído.
Os gerentes de projeto sabem isso tão bem, que cometem o erro de não achar que seja necessário conhecer sua equipe, uma vez que não teria mais contato com estes após a conclusão do projeto.
O gerenciamento de projetos é um esforço em equipe. Se o gerente não conhecer a equipe, então seus membros não poderão se sentir como se fossem parte desta. sabe-se que uma equipe pode promover melhor comunicação, cooperação, trabalho e confiança.
E se você não acredita que isso é importante, tente gerir um projeto de forma indiferente e veja o que acontece.


ERRO # 18: Não isolar a equipe das questões políticas do projeto
Fatores ambientais da empresa, especialmente aqueles de origem política, não devem afetar o desempenho da equipe. Cabe ao gerente de projeto e ao patrocinador isolar a equipe destes fatores.
Questões políticas podem fazer com que os membros da equipe percam seu senso de direção sobre o projeto e o desempenho será reduzido. Além disso, os membros da equipe que não são politicamente astutos podem envolver-se em áreas onde eles têm conhecimento limitado, o que pioraria a situação.


ERRO # 19: Não querer dizer "Não"
A palavra "não" poderia muito bem ser a palavra mais importante no vocabulário de um gerente de projeto. Tanto para tratar as relações com o cliente, como da equipe.
Após o go-live do projeto, os clientes (muitas vezes) tentam convencer o gerente a aceitar mudanças no escopo sem custo, a fim de manter o cliente satisfeito. Isso pode levar a conseqüências desastrosas...
Outra razão para dizer não é quando os membros da equipe reclamam que estão sobrecarregados de trabalho e tentar transferir parte desta carga para o próprio gerente. Embora seja verdade que os gerentes de projeto são, ao mesmo tempo, gestores e executores, eles devem conhecer suas próprias limitações.


ERRO # 20: Selecionando corretamente o campo de batalha
Para ser bom em fazer guerra, é preciso saber quando atacar, quando defender e quando sair em retirada, a fim de lutar novamente. Os gerentes de projeto inexperientes tendem a não entender corretamente quando lutar e quando desistir. Em vez disso, eles acabam lutando batalhas que deveriam ser combatidas por outros, ou por todos. Os gerentes de projeto deve saber se o campo de batalha é bom para eles.




NOTA:
Obviamente, esta lista não é exclusiva. No entanto, ele fornece algumas orientações sobre o tipo de problemas que os gerentes de projeto devem entender. Estes erros podem ser corrigidos e, assim, economizar tempo e dinheiro.


----------------------------------------------------------------------------------------------
Dr. Harold Kerzner (Ph.D., MS, Engenharia, MBA) é Senior Executive Director do International Institute for Learning, Inc., e professor de Sistemas de Gestão de Baldwin-Wallace College. Ele é um especialista nas áreas de gerenciamento de projetos, gestão da qualidade total e planejamento estratégico. Dr. Kerzner é o autor de livros best-seller, incluindo o Gerenciamento de Projetos: Uma Abordagem Sistêmica do Planejamento, Programação e Controle, agora em sua nona edição.

Vinte erros mais comuns (Parte III)

(terceira parte do assunto)



ERRO # 11: Ignorando problema
Ignorar os problemas é semelhante ao erro anterior de não querer pedir ajuda. No entanto, ignorar um problema também pode parecer (para o cliente) que o gerente do projeto poderia tê-lo resolvido e não deu a devida importância. Assim, o problema logo se materializará.
Os problemas não vão embora. Em vez disso, eles aumentam de tamanho e as possibilidades de realizar uma solução pode diminuir, aumentando significativamente os riscos. Saber de um problema e não tomar nenhuma ação resolutiva pode ser visto como um "beijo da morte" pelo patrocinador e até mesmo se tornar o objeto de rescisão do projeto.


ERRO # 12: Acreditar em salvadores e milagres
Talvez a razão mais comum para não pedir ajuda ou ignorar o problema é que o gerente do projeto está à procura de um salvador ou de um milagre para resolver o problema. Ainda que os milagres possam ocorrer, tais como um rápido e repentino avanço técnico, as chances de isso acontecer são muito, muito baixas.

Os gerentes de projeto precisam desenvolver, logo no início do projeto, uma estratégia para lidar com os problemas. A esperança não é uma estratégia. Pelo contrário, é uma forma distorcida de racionalização para evitar um problema.


ERRO # 13: Prometer recompensas
Os gerentes de projeto inexperientes, muitas vezes, fazem promessas de recompensas, mesmo sabendo que eles não têm muita responsabilidade sobre os salários e vencimentos. No
entanto, acreditam que esta é uma forma eficaz de motivar a equipe. Os gerentes de projeto não podem fazer promessas de promoção, horas extras, gratificações, trabalhos futuros trabalhos e outras questões, mas persistem em fazê-lo.
Os membros mais experientes da equipe sabem o que um gerente de projeto pode e o que não pode prometer ou cumprir. O resultado é uma equipe desmoralizada, com pouca confiança no seu  gerente. Estes mesmos profissionais, também podem se recusar a trabalhar para este gerente do projeto no futuro.


ERRO # 14: Não ver dependências entre projetos
Os gerentes de projeto inexperientes muitas vezes ficam tão encantados com seus projeto que eles não conseguem ver mais nada à sua volta. O resultado é que eles acabam tomando decisões que são as melhores para o seu projeto, sem se importar com o todo.
Os gerentes de projeto devem estar dispostos a negociar suas decisões levando em conta a necessidade da empresa, e não apenas as do projeto, e isso requer uma compreensão das dependências entre os projetos e as atividades em curso. 
Lutando pelos melhores recursos da empresa não pode ser uma boa decisão, se esta for levada apenas pelas necessidades do seu projeto, principalmente se o seu projeto tiver uma prioridade muito baixa em comparação com outros projetos da empresa.


ERRO # 15: Não informar o cliente que estão errados
Acreditar que o cliente tem sempre razão não é necessariamente a postura mais correta em gerenciamento de projetos. Embora os gerentes de projeto pretendem apaziguar os clientes, eles  devem estar dispostos a dizer: "Sua decisão ou idéia está errada".
Isto é particularmente verdadeiro quando os clientes solicitam alterações no escopo, ou simplesmente mudar o rumo do projecto, sem compreender totalmente suas ramificações. Algumas pessoas acreditam que a palavra mais importante no vocabulário de um gerente de projeto é "não".


(última parte na próxima semana)

Vinte erros mais comuns (Parte II)

(continuando da semana anterior)

Erro # 6: Não compartilhar responsabilidades com os gerentes funcionais

Nos primórdios da gestão de projeto, os gerentes dominavam a tecnologia.

Quando surgiam as necessidades de alocar pessoal, os gerentes de projetos negociavam recursos específicos que ficariam alocados sob sua direção técnica e não de um gerente funcional. O gerente funcional ainda manteve o controle sobre a administração de seus recursos, fora de um projeto.  Hoje, os gerentes de projeto têm apenas uma compreensão da tecnologia e, portanto, deve negociar com os gerentes funcionais suas necessidades de entregas e não de pessoas.

Os gerentes de projeto inexperientes acreditam que eles têm a responsabilidade exclusiva sobre a pessoa e, também, a responsabilidade para o sucesso do projeto. É um erro para o gerente de projeto não compartilhar esta responsabilidade com os gerentes funcionais, mesmo que esta situação não faça parte da atual cultura corporativa.

Erro # 7: Melhorias sem fim

A maioria dos gerentes de projeto quer encantar o cliente. No entanto, há limites que devem ser observados. Melhorar indefinidamente uma entrega após seu escopo ter sido alcançado pode sair muito caro.

Além disso, o cliente pode acreditar que eles sempre poderão obter essas melhorias sem custo em projetos futuros, pois um novo padrão foi definido.

Erro # 8: Não compreender o que os interessados e os patrocinadores querem ouvir

Um dos requisitos para passar no exame PMP® é a compreensão da Gestão de Custos e, mais especificamente, as fórmulas atribuída a medição de valor agregado.

Embora não haja o mérito deste, reportar uma métrica para o valor agregado é apenas parte do que as partes interessadas e os patrocinadores querem ouvir. É imperativo que, como parte da gestão de stakeholders, gerentes de projeto entrevistem os interessados para saber quais informações que estes consideram importantes.

Todos os interessados podem querer um conjunto diferente de monitoramento de métricas e indicadores de desempenho (KPI). O gerente de projeto pode achar que é necessário desenvolver um painel de desempenho diferente para cada uma das partes interessadas. Isso poderia incorrer em custos significativos, se não previstos para o orçamento.

Erro # 9: Não entender completamente os requisitos do projeto

Os mais inexperientes gerentes do projeto, na maior parte do tempo, tenderão a utilizar suas próprias interpretações dos requisitos, em vez de consultar a especialistas no assunto. Isso pode levar a desorientação na abordagem técnica e as modificações onerosas nas fases posteriores do projeto.

Muitas vezes, não é o gerente de projeto o elo inicial entre as partes interessadas, mas o pessoal de vendas e marketing. O gerente do projeto, em seguida, herda as exigências do projeto e pode não estar plenamente conscientes dos pressupostos utilizados na elaboração da proposta comercial.

ERRO # 10: Recusando-se a pedir ajuda

Um dos erros mais comuns cometidos pelos gerentes de projeto inexperiente é a crença de que a pedir ajuda irá fazê-los parecer incompetentes aos olhos dos seus pares e subordinados. Nada poderia estar

mais longe da verdade. Bons gerentes de projeto reconhecem seus limites e busca ajuda com a maior brevidade possível.

Recusar-se a procurar a ajuda pode resultar em desvios de cronograma e custos excessivos. Se gerente de projeto perde muito em busca de ajuda, o número de opções para corrigir o problema pode diminuir. Os patrocinadores devem encorajar os gerentes de projeto a pedirem ajuda no momento mais próximo possível. No entanto, deve ficar claro que o patrocinador não é a área de escape para todos os problemas que o gerente de projeto não pode resolver.

(continua na próxima semana)

Vinte erros mais comuns (Parte I)

Para ler o original, clique abaixo:
Vinte erros comuns cometidos pelos gerentes de projeto novos ou inexperientes.
Por Harold Kerzner, Ph.D., PMP



Você já leu o PMBOK® diversas vezes, fez o exame de certificação para gerentes de projeto, passou, e agora você é um PMP®. No entanto, descobre que os erros persistem. 
Os gerentes de projeto não são infalíveis. A maioria dos cursos de formação em gestão de projeto, mesmo as que incidam sobre o Guia PMBOK®, estressam o tema dos "geralmente aceitos como as melhores práticas"". O que não é ensinado são as discussões sobre o que não se deve fazer como um gerente de projeto.


A lista abaixo mostra vinte dos erros (neste post, os cinco primeiros) mais comuns que os gerentes de projetos jovens ou inexperientes costumam fazer. Obviamente que há mais de vinte erros e, muitos deles, podem ser exclusivo para indústrias ou situações específicas. No entanto, a lista é um bom ponto de partida para entender por que muitos gerentes de projeto entram em apuros por causa de suas próprias atitudes.


Erro # 1: Detalhamento excessivo
Gerentes de projeto inexperientes tendem a ficar encantados com a estruturação das atividades de um projeto (sigla em inglês WBS: Work Breakdown Structure).
Um gerente de projeto recém-nomeado me pediu para rever a sua WBS para um projeto de TI. O projeto de trinta dias tinha 340 pacotes de trabalho e alguns dos pacotes de trabalho foram divididos em minutos em vez de horas ou dias. Enquanto o gerente estava orgulhoso de sua realização na criação de um WBS em "nível micro", ele se recusou a considerar a quantidade de tempo e o esforço exigidos pela equipe para gerenciar esse nível de detalhe. O custo envolvido para estabelecer as 340 atividades e monitorá-las poderia facilmente aumentar o custo de apoio à gestão do projeto, em cinqüenta por cento ou mais.
Os gerentes de projeto deve estabelecer um nível adequado de WBS para gerir. Criar uma WBS altamente detalhada é um convite para microgerenciar um projeto, alienando assim os gerentes funcionais. A maioria dos gerentes de projeto hoje não possuem conhecimentos técnicos para criar uma WBS detalhada, sem assistência funcional. Apenas imagine-se aprensentando na reunião de kick-off para um projeto de trinta dias e sendo entregue uma WBS com 340 pacotes de trabalho...


Erro # 2: Fingindo saber mais do que você realmente conhece
Na maior parte dos casos, os gerentes de projeto que possuem hoje uma compreensão da tecnologia ao invés do domínio desta tecnologia, ainda persistem na tentativa de tomar decisões técnicas sobre o projeto.
O tamanho e a complexidade dos projetos de hoje devem deixar claro para os gerentes de projeto que devem depender dos especialistas no assunto e levar um apoio funcional para a dar a direção técnica do projeto. Em alguns projetos, como em R&D (pesquisa e desenvolvimento), as atribuições de gerente de projeto pode ser ditada pela necessidade de domínio de uma tecnologia ao invés de apenas sua compreensão, mas esta é uma exceção e não a regra.
Bons gerentes de projeto sabem das suas limitações e não tentar impor uma solução sem consultar primeiro com os verdadeiros especialistas.


Erro # 3: Preparar uma agenda ambiciosa
Quanto mais inexperientes o gerente de projeto, mais otimista se tornará quando da
elaboração de um cronograma inicial.
Embora metas ambiciosas possam ser interessantes, elas são frequentemente irrealistas e podem piorar a situação com os clientes, para os quais nunca é dito que o cronograma é ambicioso e, portanto, acreditam que o cronograma seja realista.
Os clientes passam a focar as datas marco e agora, quando o um deslizamento de metas mostra-se ambiciosas demais para a realidade, você tem um cliente insatisfeito que quer saber quais outras surpresas aparecerão adiante.
Outro fator a considerar é o impacto dessas agendas sobre as estimativas funcionais. Cronogramas ambiciosos podem exigir que os membros da equipe estejam em uma posição mais alta na curva de aprendizagem para conseguirem executar as atividades nos tempos necessários, mudando assim, os padrões funcionais. Além disso, tais atividades podem demandar mais comprometimento da equipe quanto seus horários permitem, tornando o cronograma irreal.


Erro # 4: Dependência excessiva de processos repetitivos
As empresas podem levar anos na criação de uma metodologia Enterprise Project Management (EPM). A intenção é que a metodologia seja utilizada em todos os projetos para todos os clientes e do início ao fim de qualquer projeto.
Embora a intenção tenha mérito, metodologias de EPM não servem para todos os problemas possíveis que poderão existir em cada projeto. Ter fé absoluta na expectativa de que os processos repetitíveis irão resolver seus problemas é um erro. Os processos repetitivos aparecem na forma de diretrizes, formulários, modelos e listas de verificação. processos repetitivos não são uma substituição ou substituto para a atenção da administração, a partir de tomada de decisão, ou resolução de problemas.
Eles são apenas ferramentas para o gerente de projetos utilizar e, como todos sabemos, os projetos são geridos por pessoas e não ferramentas.


Erro # 5: Ignorando problemas
Todos os projetos têm problemas.
Gerentes de projeto inexperientes gastam boa parte do tempo necessário para resolver estes problemas apenas para descobrir que os custos de corrigir estes problemas mais tarde (que não no ciclo de vida do projeto) foi significativamente mais caro do que se os reparos tivessem acontecido nas fases anteriores do projeto.
Os gerentes de projeto não podem ser seletivo em quais problemas resolver. Todos os problemas do projeto devem ser abordados e quanto mais cedo, melhor. Embora seja verdade que os gerentes de projeto podem não ser capazes de resolver os problemas eles mesmos, eles deveriam pelo menos saber quais são os especialistas no assunto de que necessitam para resolver tais questões.


(continua na próxima semana)