PDF

AS 10 PIORES PRÁTICAS DO PMO: ARMADILHAS QUE DEVEM SER
EVITADAS
Pesquisa feita pelo Gartner estima que os Escritórios de Gerenciamento de Projetos (PMOs)
possuem uma taxa de fracasso de 50% ou mais em sua primeira tentativa de implantação. O
Daptiv se comprometeu com centenas de clientes corporativos para ajudar a garantir que eles
obtenham sucesso no PMO de suas organizações desde o início e consigam evitar armadilhas
comuns que levam ao fracasso da iniciativa. Com base em nossa experiência, fizemos uma
compilação das 10 piores práticas dos escritórios de gerenciamento de projetos que já
identificamos e incluímos orientações sobre como evitá-las.
1. O Jogo da Metodologia do PMO.
Se existe um refrão comum para PMOs fracassados, ele é o seguinte: O PMO se torna sinônimo
de uma “Política de Metodologia” que é encarregada de fazer com que a metodologia seja
cumprida, muitas vezes mal conduzida, de forma rigorosa. Na melhor das hipóteses, levará a
reclamações dos gerentes de projetos, e na pior das hipóteses, levará à insatisfação, não adesão
e à não observância de toda a metodologia. Em vez de se tornar um apoio e guia para gerentes
de projetos criando consistência, credibilidade e melhores resultados em práticas de
gerenciamento de projetos, esse PMO se tornou o pior inimigo do gerenciamento de projetos. O
PMO perde visibilidade dentro do portfolio do projeto e constantemente falha devido à falta de
apoio das partes e áreas envolvidas.
2. Implementando uma metodologia sem framework.
Nós vimos muitos PMOs tentarem implementar um Ciclo de Vida de Desenvolvimento de
Software (SDLC) em sua organização. Isso é ótimo para algumas equipes de desenvolvimento
de software, mas pode ser completamente inadequado para equipes de melhoria de processo e
infraestrutura. Uma estrutura melhor é um framework global de gerenciamento de projetos, que
inclui apenas as fases e “gates" básicos e alguns poucos artefatos de controle (caso de
negócios, cronograma do projeto, relatórios de status, etc.). Esse procedimento é conhecimento
como Ciclo de Vida do Projeto e muitos podem se encaixar no framework e serem moldados
conforme as necessidades da organização e características do projeto.
3. Não Implementação de Metodologia.
Nós estamos nos contradizendo? Na verdade não. Se o gerente de projetos não implementar
alguma forma de framework abrangente, não será possível criar uma visão geral e uniforme dos
projetos constantes do portifólio. Contudo, a metodologia é exigida para assegurar consistência
SBN Quadra 2 Bloco “F” Sala 313 – Asa Norte – Brasília/DF – CEP: 70.041-906
www.g4f.cm.br
na execução do projeto e para reduzir os riscos decorrentes da falta de experiência de gerentes
de projeto. Por exemplo, um novo gerente de projetos pode não fazer o planejamento adequado
do projeto, da atribuição de tarefas ou das avaliações de riscos, causando problemas e fazendo
com que sejam necessários grandes esforços para que o projeto seja colocado novamente nos
trilhos. Assim, estabelecer uma metodologia é essencial – ou talvez várias no caso de um
framework abrangente. Finalmente, regulamentos federais, especialmente a Sarbanes-Oxley,
exigem metodologias que estejam em conformidade com certos processos, alterando alguns
requisitos do gerenciamento.
4. Não dimensionamento e gestão de recursos.
Nas reuniões do comitê de direção, o foco quase sempre é na priorização. Isto é uma coisa boa,
já que os processos de priorização resultam em um bom entendimento da demanda do projeto.
No entanto, quando é necessário decidir quantos dos projetos podem realmente ser realizados, a
discussão muitas vezes se transforma em meros palpites de trabalho como, por exemplo, no
caso em que uma pessoa é questionada a respeito da sobrecarga de seu departamento. Sem um
entendimento e correto dimensionamento da capacidade de recursos baseado em números, é
impossível corresponder de forma perfeita com a provisão real de recursos humanos à demanda
que foi solicitada.
5. Não Registrar o Tempo.
Esta é, na verdade, a fonte da pior prática número 4. É impossível saber a real capacidade de um
departamento sem marcar o tempo efetivo que foi gasto nos projetos atuais e em outros
trabalhos. Planejar, ainda que no nível mais detalhado possível, é uma mera suposição se não
envolver o histórico e feedback do tempo real de projetos similares realizados.
6. Armazenar Informações Desnecessárias.
PMOs são ótimos em coletar e reunir todos os tipos de estatísticas. Ora, mas se aquela
informação não for utilizada no processo de tomada de decisões, para que armazená-la? Isso
apenas cria uma carga extra na equipe responsável pelo projeto sem gerar qualquer resultado
útil. Um exemplo disso é a coleta de dados no nível de tarefas detalhadas, incluindo pequenas e
óbvias tarefas diárias como “Colocar tempo”, “Responder e-mail” e “Comparecer à reunião de
pessoal”. Isso pode ser um lembrete útil para tarefas, mas para planejar objetivos, tudo o que
precisamos saber é quanto tempo cada recurso está levando para desempenhar tarefas;
7. Manter um processo ad-hoc de solicitação de projeto.
SBN Quadra 2 Bloco “F” Sala 313 – Asa Norte – Brasília/DF – CEP: 70.041-906
www.g4f.cm.br
O processo mais comum para lidar com novas solicitações de projeto é analisá-las uma por uma
e decidir quais merecem se tornar um novo projeto. Mas o que fazer com relação às outras 100
solicitações? Qual é a prioridade? Atualizar as solicitações e ordens de serviços nos servidores
pode ser importante, mas é mais importante do que o novo data center? Se você avaliar as
questões isoladamente, então o próximo projeto importante poderá afetar um projeto já em curso,
até que seja afetado por um novo projeto emergencial. O resultado será um sério descontrole do
projeto. A solução será analisar ciclos de solicitações cíclicas (pelo menos trimestrais) que
considerem todas as solicitações lado a lado e selecionem aquelas de maior importância para a
organização. Quantas devem ser escolhidas? Veja o número 4: Não dimensionamento e gestão
de recursos.
8. Falta de patrocínio ou suporte executivo.
Este item deveria ser óbvio, mas acontece a todo o tempo. A equipe executiva percebe que há
um problema com os projetos, que não estão sendo executados adequadamente, sob a alegação
de poucos recursos, ou que os resultados não estão sendo entregues. Então, eles autorizam um
escritório de projetos e esperam que o problema seja solucionado. Porém, chega a hora de
participar da reunião do comitê de direção e eles enviam funcionários de níveis mais baixos e
não lhes dão autoridade para tomada de decisões. Ou, pior ainda, eles passam por cima das
decisões do escritório de projetos. Então, quando os projetos, mais uma vez, estão tendo
desempenho ruim devido à falta de recursos e conflitos de prioridades, eles culpam o escritório
de projetos e o eliminam.
9. Implementar uma ferramenta sem um processo.
É outro problema óbvio, mas comumente visto. Se você está implementando uma solução PPM
ou um sistema ERP, automatizar processos ruins ou não existentes apenas fará com que os
problemas cheguem a você mais rapidamente! Departamentos de TI são particularmente
inclinados a achar que a ferramenta é a solução, mas é surpreendente o número de
organizações que caem nesta mesma armadilha. A desculpa mais comum é que a ferramenta já
possui melhores práticas incorporadas, então porque não seguí-las? Na nossa experiência, cada
organização é diferente e precisa fazer seus próprios ajustes nas “melhores práticas”.
10. Implementar um processo sem uma ferramenta.
O conselho padrão é desenvolver o seu processo antes de automatizá-lo com uma ferramenta.
Nós já vimos muitos escritórios de projetos que seguiram esse conselho e acabaram tendo
problemas. Processos complexos executados em planilhas e documentos são muito onerosos e
a onerosidade excessiva pode sabotar a escolha. Nós descobrimos que é muito melhor
SBN Quadra 2 Bloco “F” Sala 313 – Asa Norte – Brasília/DF – CEP: 70.041-906
www.g4f.cm.br
implementar o processo e a ferramenta ao mesmo tempo e isso traz algumas vantagens.
Primeiro você pode desenvolver o novo processo para tirar vantagem dos pontos fortes do
software escolhido. Você teria que ajustá-los durante a implementação de qualquer forma, então,
você já pode fazê-lo enquanto desenvolve o processo. Segundo, usuários aprendem o novo
processo na nova ferramenta, o que significa uma curva de aprendizado, ao invés de duas.
Finalmente, o seu novo processo tem uma maior chance de sucesso através da racionalização e
automatização desde o começo. Deve-se tomar cuidado com o seguinte: quando algo dá errado,
você realmente precisa diagnosticar se é um problema do processo ou da ferramenta. O software
é um ótima bode expiatório inanimado, mas quase nunca é o real problema.
SBN Quadra 2 Bloco “F” Sala 313 – Asa Norte – Brasília/DF – CEP: 70.041-906
www.g4f.cm.br