Grandes Verdades sobre o Gerenciamento de Projetos

Existem algumas verdades sobre Gerenciamento de Projetos que precisam ser relembradas, sempre.

| View | Upload your own

Certificação x Competência: quem manda e quem obedece?

Esses dois temas são frutos de muita discussão, não apenas pela sua importância na formação de valores, mas, sobretudo pela maneira como eles se relacionam. Em outras palavras, busca-se entendem até que ponto eles se confrontam ou se complementam?

O que apresentamos abaixo são trechos do artigo publicado por Rodrigo Campos no seu blog, que faz uma visão atual do cenário, abre caminhos a observações diversas e favorece para que análises sejam feitas de forma objetivas e esclarecedoras. Muito interessante.

" ...Atuo no mercado da tecnologia da informação (TI). TI tem como principal produto “conhecimento que gera tecnologia”. Bill Gates e Steve Jobs, fundadores da Microsoft e Apple, respectivamente, são expoentes mundiais da TI. Suas empresas dispensam maiores apresentações, basta dizer que são marcas mundiais e que o faturamento delas é maior que a riqueza de países.

O que Bill e Steve têm em comum? Além da fortuna, da vocação empreendedora e da notoriedade mundial, nenhum deles completou sua formação acadêmica superior. Alguém duvida da competência deles? Os resultados desses profissionais não dão margem a esse tipo de dúvida. Eles são competentes!(...)

Por outro lado, ao longo da carreira, já analisei centenas de currículos e fiz uns sem-número de entrevistas. Confesso que tenho apreço por essa tarefa dado meu interesse por formar equipes, encontrar talentos e entender meus pares.(...)

“Ter” um título ou determinada certificação, tornou-se mais importante que “ser” aquilo que o título ou certificado confere. Conheci gerentes que não sabiam gerenciar. Analistas que não sabiam analisar. Administradores que não sabiam administrar, entre outros exemplos que optei por não citar. (...)

Criou-se uma indústria paralela em torno da formação. Ganham com isso as instituições oportunistas que formam e oferecem ao mercado cada vez mais profissionais menos preparados. Perdem os profissionais que investem e não obtém o conhecimento pretendido. Perdem as instituições sérias. Perdem as empresas que compram conhecimento que não existe.

Minha posição sobre “Ter” ou “Ser”? Digo que é melhor que o profissional procure o equilíbrio entre as duas coisas. É tão importante que ele obtenha títulos e certificações, quanto é necessário que ele seja aquilo que disser que é.

Complemento agora esta reflexão relatando um frase também atribuída a Nietzsche, citada em um dos comentários que já recebi sobre este tema, que traduz e sintetiza tudo aquilo que tentei dizer com este texto: “Torna-te aquilo que és!”..."

Para ver o artigo completo acesse o blog do Rodrigo Campos.

Aprendendo a dizer Não

Dizer não a alguém no cotidiano é uma tarefa, para muitos, indigesta. Em gerência de projetos não é diferente, visto que há sempre campo para se usar essa palavra, seja em resposta a uma solicitação de inclusão de recurso no projeto, em uma conversa ou reunião de planejamento, pedidos de membros da equipe, etc. Na verdade, dizer não é uma arte e um talento que o responsável estratégico ou tático por projetos precisa desenvolver e cultivar, para o bem de sua equipe e mesmo de seus resultados. Além disso, deve saber usar somente nos momentos corretos, para poder dizer “sim” ao que de fato é estratégico e crítico.

Para superar mais esse obstáculo, é necessário conhecer os diversos sabores em que é distribuída a palavra “não”, segundo o livro “The Art of Project Management” (A Arte do Gerenciamento de Projeto)(BERKUN, Scott. O’Reilly, 2005), no capítulo “How to make things happen” (Como fazer as coisas acontecerem):

Não, isto não se encaixa em nossas prioridades: Se ainda é cedo no calendário do projeto, você deve argumentar sobre a razão por que as prioridades atuais são boas, mas ouvir os demais que queiram defender por que outras prioridades podem fazer mais sentido. Eles podem ter boas idéias, ou precisar de esclarecimento sobre as metas. Mas restrinja a discussão para que seja sobre as prioridades do projeto, e não sobre o valor abstrato de um recurso ou solicitação de manutenção. Se já for tarde no calendário do projeto, pode ser interessante informar claramente ao solicitante que ele perdeu o barco. Mesmo que as prioridades não sejam as melhores, elas não podem mudar por causa de uma idéia de novo recurso. Quanto mais avançado você estiver, mais severa deve ser a falha estratégica para permitir ajuste de metas.

Não, só se tivermos tempo: Se você mantiver suas prioridades em forma, sempre haverá muitas boas idéias que não terão sido aprovadas. Expresse isso como uma decisão relativa: a idéia em questão pode ser boa, mas não boa o suficiente em relação a outras idéias, e às prioridades do projeto. Se o item estiver na lista da “prioridade 2?, sustente que é possível que ele será feito, mas que ninguém deve apostar muito alto nisso.

Não, a não ser que você faça [insira o fator complicador aqui] acontecer: Às vezes você deve redirecionar a solicitação de volta a quem a fez. Se o seu vice-presidente consulta sobre a possibilidade de incluir um novo recurso, você pode responder que é possível dentro das metas correntes, desde que ele corte alguma outra da sua lista de prioridades. Isto faz com que a equipe deixe de ser o ponto de contenção, e aponta um fator externo tangível, embora possivelmente insolúvel, de bloqueio. Isto também pode ser usado para questões que dependam de política interna: “Se você convencer a Diretoria de Finanças de que isto é uma boa idéia, vamos considerá-la”. Mas esteja preparado para honrar sua palavra caso o solicitante consiga resolver a questão.

Não. Próxima versão: Assumindo que você está trabalhando em um projeto de website ou software que terá mais atualizações, ofereça reconsiderar a questão na próxima versão. Isto deve acontecer sempre e automaticamente para todos os itens de prioridade 2.

Não. Nunca. Mesmo: Algumas solicitações são tão fundamentalmente desalinhadas em relação às metas de longo prazo, que o martelo deve ser batido imediatamente. Corte a corda agora mesmo e economize o tempo de responder mais uma vez à mesma questão no futuro. Às vezes vale a pena explicar detalhadamente a razão, para que o solicitante esteja informado no futuro. Exemplo: “Não, o sistema de divulgação não irá oferecer suporte ao idioma Esperanto. A política é de suporte apenas a idiomas nativos de países em que tenhamos usuários.”

Boas Práticas

O que fazer para salvar o projeto se o cronograma está atrasado?

Se você percebeu o atraso no cronograma do projeto, não se desespere. Segundo Capers Jones (Assessment Control on Software Risks), alguns índices devem ser considerados:

• 70% dos grandes projetos sofrem de instabilidade de requisitos;
• Pelo menos 50% dos projetos são executados com níveis de produtividade abaixo do normal;
• Pelo menos 25% dos softwares de prateleira e 50% dos feitos por encomenda apresentam mais defeitos do que o razoável;
• Pelo menos 50% dos grandes projetos de software estouram seu orçamento e prazo.

Não se deve, porém, perder mais tempo com justificativas nem tão pouco considerar que o atraso não precisa de uma tratativa imediata. O primeiro passo é analisar a situação. É fundamental descobrir as causas do desvio. Seguir adiante sem uma criteriosa análise poderá aumentar alguns fatores de risco a ponto de se tornar impraticável seu gerenciamento.

Discuta os pontos críticos com um observador externo.

Um observador externo (outro gerente de projeto) poderá avaliar a situação de forma neutra e perceber detalhes que não tenham sido considerados. É natural, em situações de crise, que os membros do grupo hajam de forma tendenciosa, deixando que pequenos detalhes causem grandes problemas. Não hesite em pedir ajuda.


O que levou ao desvio?

Identificar corretamente as causas do desvio contribuirá significativamente para a negociação e o realinhamento do projeto aos seus objetivos iniciais.

As mais prováveis causas de desvio estão citadas abaixo:

• Desconhecimento ou desconsideração da importância de um ou mais interessados do projeto;
• Ausência de padrões e/ou métodos, desde o gerenciamento até a implementação do projeto;
• Requisitos mal definidos, entendidos ou implementados;
• Estimativas falhas ou excesso de otimismo durante a estimativa;
• Tentativa de implementação de todos os requisitos que surgem no decorrer do projeto sem que seja feita uma renegociação do prazo inicial;
  Aceitação por parte do gerente do projeto de um cronograma imposto e virtualmente impossível de ser cumprido;
• Aceitação por parte do gerente do projeto de uma diminuição de prazo sem a contrapartida de aumento dos recursos;
• Mudanças constantes das prioridades por parte dos interessados;
  Ausência de um estudo detalhado e planejamento de riscos;
• Mudanças constantes na equipe de projeto.
• Inexperiência da equipe em relação às metodologias ou tecnologias utilizadas no projeto;
• Utilização de tecnologias novas, sujeitas a prováveis falhas futuras não catalogadas.

Ataque o problema por partes e retome o controle aos poucos.

Tratar o conjunto de problemas identificados deve ser considerado um novo projeto.
Decomponha o problema em partes mensuráveis, atribua um responsável, desenvolva uma estratégia para abordá-las e crie um novo cronograma onde todas as tarefas estejam especificadas como “têm de ser feito” (essenciais) ou “deveria der feito” (serão excluídas do escopo) ou “poderia ser feito” (poderão ser incluídas no escopo), levando-se em conta as expectativas do cliente.


Comunique-se. Negocie.

Segundo a Metodologia PMBOK, a comunicação é uma ferramenta que deve ser utilizada em 90% do tempo do gerente de projetos e a negociação é uma das habilidades indispensáveis aos gerentes de projetos. Em momentos de crise elas serão ainda mais importantes. Novos prazos, custos, mudanças de escopo, características do produto deverão ser renegociados, ou seja, o projeto deverá ser tente redimensionado conforme a nova capacidade de trabalho. Vale lembrar que produtos feitos sob pressão de prazos poderão ter sua qualidade comprometida.

Nesse momento, os riscos precisam ser minimizados através de negociações vantajosas para ambos os lados, sendo fundamental manter o cronograma proposto e a distribuição das tarefas nas três categorias. A nova proposta deverá ser clara e viável de forma que o cliente acredite que as tarefas eleitas serão realmente implementadas no prazo e custo combinados e com a qualidade desejada.

Todos os aspectos deverão ser considerados, pois uma nova negociação será muito difícil, ou quase impossível.

Outra opção seria dividir o projeto em módulos funcionais onde que possam satisfazer o cliente dando um novo fôlego à equipe do projeto para que possam implementar as entregas posteriores com certa tranqüilidade.

É importante também rever a lista de interessados (stakeholders) do projeto para que sejam envolvidos todos aqueles que têm relação direta ou indireta com o projeto, pois, gerenciar interesses e interessados com expectativas diferentes é uma tarefa que requer muito conhecimento sobre esse conjunto de variáveis.

Vale lembrar...

Todos os índices devem ser revistos periodicamente de forma a se avaliar sua adequação ao projeto. A modelagem e o desenho do projeto deverão ser validados e, se necessário, completamente substituídos caso seja verificado que aumentarão os esforço de implementação.

De nada adianta a equipe trabalhar horas e horas a fio, após o horário e durante o final de semana no início do cronograma. O stress causado na equipe pode comprometer o adiantamento do prazo conseguido, pois o cansaço dos membros da equipe pode vir a gerar uma quantidade excessiva de falhas, que causarão o dobro de retrabalho nas próximas semanas. Planeje o esforço dobrado para sua equipe para os momentos finais de cada marco no cronograma, intercalando o esforço de cada um com períodos de descanso alternados entre os membros.

Analise a equipe inicial do projeto. Várias falhas no projeto inicial podem estar relacionadas com o desempenho da equipe ou do gerente em relação a ela. Não reinicie o projeto sem a certeza do comprometimento de todos. Caso venha a notar qualquer problema em relação aos membros da equipe, negocie as substituições necessárias antes do início do projeto. Faça essa verificação, na medida do possível, em conjunto com a equipe, deixando “às claras” toda a situação. A equipe deve ver em você um líder; deve confiar na sua lealdade para com todos. Caso contrário, não haverá comprometimento. Isto quer dizer que você deve não só se preocupar com o quanto a equipe pode contribuir no projeto, mas também com o quanto você pode contribuir com a equipe.
O gerente que vivencia os problemas de sua equipe está trabalhando para o sucesso do projeto.

Construindo Resultados com Gerenciamento de Projetos - Parte III

Parte final da entrevista concedida por Ricardo Vargas para a Microsoft. Nela ele apresenta visões valiosas a respeito da gerência de projetos.

Construindo Resultados com Gerenciamento de Projetos - Parte II

Continuação da entrevista concedida por Ricardo Vargas para a Microsoft. Nela o especialista discute os principais temas relacionados ao gerenciamento de projetos no Brasil e no mundo.

A Organização PMI - Project Management Institute

• Associação Profissional sem fins lucrativos
• Fundado em 1969
• Matriz da Organização em Newtown Square, Pennsylvania USA
• Centro Regional de Serviços em Bruxelas, Bélgica
• O número de filiados ao PMI subiu para mais de 250.000 em mais de 170 países.

Seus Produtos e Serviços

O Guia Padrão: Project Management Body Knowledge – PMBOK

É um conjunto de práticas em gerência de projetos levantado pelo PMI que constituem a base da metodologia de gerência de projetos do PMI. Estas práticas são compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK.

Também encontrado no formato On-line no site do CBTA - Centro Brasileiro de Tecnologia e Automação.

A Certificação em Gerenciamento de Projetos

O Exame de Certificação PMP é oferecido em todo o mundo através de estações de computadores em centros autorizados.

A língua oficial do exame de certificação PMP é o inglês. Entretanto os candidatos podem escolher entre outras sete línguas para auxílio durante a prova. As opções são o Português Brasileiro, Chinês, Francês, Alemão, Italiano, Japonês, Coreano e Espanhol.

O Programa de Certificação PMP, do PMI, recebeu a certificação ISO 9001 sendo o primeiro programa de certificação no mundo a obter esta credencial.


A importância da Certificação

• Reconhecimento pessoal e profissional na equipe
• Acelera o crescimento profissional pelo desafio
• Cria oportunidades novas de trabalho na organização
• Facilita a troca de experiência e a adoção de padrões dentro da organização
• Eleva o valor do profissional para a organização
• Empregabilidade
• Reconhecimento internacional

O site CertCities.com elegeu a certificação PMP como a 4ª mais importante certificação do mundo no ano de 2006. No ano de 2005 a certificação PMP estava em décima colocação.

O PMI também possui o seu Código de Ética e Conduta Profissional, em vigor desde 1º de janeiro de 2007 e responsável pelo regimento único da postura ética atribuída a todos seus membros, voluntários (membros ou não) e profissionais certificados.