White paper O modelo de maturidade do sistema de gerenciamento de projetos

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). Descreve como as organizações maduras podem ser mais eficientes na utilização dos sistemas de gerenciamento de projetos. Descreve como pode ser mais eficaz para as empresas optarem por usar somente determinados aspectos de um novo sistema de gerenciamento de projetos para um nível ao qual eles estão confortáveis, mesmo que tenham tendência a utilizar todos os recursos disponíveis. Conforme a empresa evolui, o uso dos recursos pode se tornar mais avançado do que a própria necessidade de utilização.

Para baixar a versão deste documento em Word, consulte White paper O modelo de maturidade do sistema de gerenciamento de projetos.

Para ver mais white papers, consulte os white papers da coluna "From the Trenches".

O Modelo de maturidade do sistema de gerenciamento de projetos

O modelo de maturidade em gerenciamento de projeto (PMM, Project Management Maturity) é um assunto muito importante hoje em dia. Inúmeros consultores têm recebido muito bem para ajudar organizações a avaliarem seu "nível de amadurecimento do projeto", o qual é quase sempre exibido hierarquicamente com “mais maduro” sendo sempre melhor do que “menos maduro”. Proponentes desse conceito dizem que o modelo de PMM mostra os recursos de uma organização para gerenciar projetos. Precisa-se ter uma longa conversa sobre como as organizações se tornam mais eficazes, e não sei muito bem se escalar a hierarquia do modelo de maturidade em gerenciamento de projetos nos levará até lá. Mas isso é assunto para outro dia. Se você não for fã do modelo de PMM, existe outro tipo de modelo de maturidade que eu tenho visto em organizações que usam sistemas de gerenciamento de projetos.

Quando trabalhamos com as organizações que estão implantando um sistema de gerenciamento de projetos, é muito comum descobrir que o desejo da organização é obter os benefícios de cada elemento do novo sistema que acaba de ser demonstrado pelo fornecedor. O cliente vê relatórios, telas, fluxos de trabalho e funções com os quais ele apenas havia sonhado até então e imagina um mundo onde todos aqueles recursos funcionam tão perfeitamente bem na sua organização quanto na demonstração de vendas. Normalmente, não fica muito claro para o cliente que os dados e a configuração da demonstração que estão sendo apresentados foram cuidadosamente desenvolvidos para mostrar o máximo possível do produto. No caso do Microsoft Project e do Project Server, isso excede o produto individual e inclui todo um pacote de tecnologia.

O cliente vê telas que iniciam a partir do Windows SharePoint Services ou de formulários do Microsoft Office SharePoint Server. Ele vê os recursos referentes ao Active Directory ou ao SQL Server Reporting Services. O cliente pode ver o fluxo de trabalho do BizTalk Server ou do Windows Workflow Foundation e exibir o que vem do PerformancePoint. O fluxo de dados pode acompanhar um storyboard ou um cenário de caso de uso que torna mais fácil entender os possíveis benefícios, mas acaba por dificultar a compreensão da tecnologia subjacente.

Quando conseguimos realmente fornecer os recursos nos quais o cliente está interessado, precisamos abrandar seus desejos para implantar tudo de uma vez fazendo-o ver realidade. O cliente precisa decidir como ele quer fazer negócios antes de nós cogitarmos em configurar tal funcionalidade e se este pode ser fornecido imediatamente, com configuração ou com esforços de personalização. Há alguns clientes que insistem em implantar todos os aspectos da funcionalidade que eles idealizam, e estão preparados para se aprofundar, realizar o design, o treinamento, a capacitação e o desenvolvimento da solução, bem como encontrar financiamento e tempo para implantá-la, mas essas organizações são a exceção.

O que é muito mais comum é o cliente optar por implantar os aspectos do seu novo sistema de gerenciamento de projeto para o nível com o qual já esteja familiarizado. Conforme a organização vai conhecendo melhor o sistema e os processos comerciais subjacentes, exigirá ainda mais do sistema, se tornando mais “madura” conforme ele progride. É uma progressão natural.

Na medida em que a compreensão da organização sobre um processo de gerenciamento de projetos que pode ser automatizado evolui, sua demanda para essa automação também evolui. Essa progressão natural é exatamente como os modelos de maturidade de gerenciamento de projetos ou de recursos. Saber que as organizações evoluirão mais provavelmente ao longo desses caminhos nos tornou mais eficazes quanto aos esforços que devemos empenhar para fazer uma organização ser eficaz. Estamos inclinados a concentrar-nos nas áreas do sistema do projeto com mais chances de adoção e de fornecer um retorno sobre o investimento de acordo com a maturidade do sistema do projeto da organização. Obviamente não existem duas organizações iguais, portanto moldar esse conhecimento em uma tabela não é um bom plano. É apenas a progressão mais provável tendo como base nossa experiência com muitas empresas.

Em nossa experiência, a evolução natural do uso de um sistema de gerenciamento de projetos assume cinco áreas básicas, ainda que o sequenciamento delas tenha mudado nos últimos anos em grande parte devido à tecnologia. Para começar, vamos falar sobre as cinco áreas básicas e, depois, mais para o final deste artigo, abordaremos algumas das novas mudanças que temos visto nos últimos anos.

Cinco áreas principais de um sistema de gerenciamento de projetos

1. Planejamento   . Quase sempre vemos o planejamento como uma primeira onda. Algumas organizações vão além disso. Elas elaboram um cronograma básico, embelezam o diagrama de GANTT e então o colocam na parede do escritório da equipe do projeto. As pessoas consultam o quadro de vez em quando, nostalgicamente, como se lembrassem do excelente estado do cronograma bem antes de o projeto começar.

Embora eu esteja sendo um pouco cruel com aqueles que estão só usando seu software caro de gerenciamento de projetos para fazer um gráfico de barras, isso certamente tem o seu valor. Criar um cronograma organizado faz com que os participantes do projeto pensem sobre como o trabalho deve ser feito e é muito mais eficaz do que fazer nada ou só fazer uma lista em uma planilha.

2. Acompanhamento   . O próximo elemento de nossa experiência geralmente é o acompanhamento. Uma organização que é um pouco mais "madura" no uso do seu sistema de gerenciamento de projetos não irá apenas planejar, mas também irá acompanhar seus cronogramas, atualizando-os regularmente com o progresso até o momento e até se adiantando a eles com cronogramas projetados à medida que os planos avançam. Para muitas organizações, o exposto acima já é eficaz. Elas estão planejando em seu sistema de gerenciamento de projetos e estão trabalhando o plano ao atualizá-lo regularmente e até mesmo fornecendo relatórios úteis para a gerência.

3. Gerenciamento de recursos   . Depois de tratar do planejamento e do controle, as organizações tendem a observar o problema de gerenciamento de recursos e como ele pode ser resolvido usando o sistema de gerenciamento de projetos. Os recursos podem ter vários aspectos, conforme discutido aqui antes, mas no nível mais básico, a alocação de recursos (atribuição de trabalho aos recursos) é uma etapa importante, seguida de algum tipo de análise de recursos.

4. Gerenciamento de custos   . O gerenciamento de custos é a quarta área típica, e muitas organizações nunca conseguem chegar até aqui. Em um nível básico, ter uma estimativa de custos detalhada por fase ou, melhor ainda, por tarefa do projeto é um bom começo para a contabilização de custos. Controlar os custos reais em horas ou em valores em reais é o próximo nível.

5. Avançado   . Colocarei aqui uma quinta área para assuntos "avançados", o que pode abranger uma grande variedade de tópicos que eu ainda não coloquei nas outras categorias. Não é que eles não sejam importantes, mas quando chega a quinta onda da evolução em uma organização, ela pode seguir para várias direções diferentes. Portanto, colocarei a análise de riscos, o gerenciamento de documentos e os fluxos de trabalho automatizados neste tópico. Também há áreas avançadas em cada uma das quatro áreas discutidas até o momento.

Cada um dos elementos discutidos até aqui poderia ser ainda mais explorado, e muitas vezes é assim que ocorre, à medida que o projeto amadurece e a organização entende melhor o aspecto automatizado de seu ambiente de gerenciamento de projetos.

Para o Planejamento, a progressão pode seguir para vários cronogramas integrados com vários projetos com vínculos entre os projetos ou para o gerenciamento de programa com subprojetos.

Para o Acompanhamento, a organização geralmente avança a partir de um simples progresso de porcentagem concluída, que é normalmente a qualidade mais baixa de dados de acompanhamento, até a duração restante. O acompanhamento também pode se estender a quadros de horários para fornecer um valor exato de horas trabalhadas em comparação ao plano original por pessoa.

Na área de Recursos, vemos a alocação simples de tarefas a recursos passar para o acompanhamento do andamento dos recursos, geralmente com um quadro de horários e, então, para o aspecto mais solicitado pelo EPM, o Planejamento da capacidade do recurso. Para algumas organizações, a Corrente crítica também se aplica neste caso, unindo informações de recursos e cronogramas em um só algoritmo avançado.

No que se refere aos Custos, geralmente partimos do orçamento básico para o controle dos custos reais junto às horas e o tempo para obtermos o orçamento versus variância real, e, em seguida, para o controle do Valor agregado, como é feito nos setores de Defesa e Aeroespacial.

Até mesmo a área Avançado possui tópicos avançados. Os mais populares entre eles são o método de Análise de Risco Monte Carlo e integração da metodologia de gerenciamento de projeto (especialmente no setor de TI).

Áreas básicas e avançadas de um sistema de gerenciamento de projetos

A maioria das organizações progride ao longo de todos os cinco elementos básicos, à esquerda no gráfico acima, na ordem que acabo de demonstrar antes de se dedicar a qualquer uma da áreas avançadas. Algumas acreditam que seus desafios de gerenciamento de projeto específicos as obrigam a se concentrarem em algum desses elementos antes dos outros. O que é extremamente difícil e quase nunca dá certo é tentar ser mais maduro do que você é de fato.

É muito comum, por exemplo, que uma organização deseje ter um Planejamento da capacidade de recursos, mas, ao analisar as competências e a experiência dessa organização, você percebe que ela não estabeleceu a base necessária para criar um sistema de planejamento de capacidade de recursos. Uso com frequência o planejamento da capacidade como exemplo de porque é tão importante saber em que ponto você está no modelo de maturidade do sistema de gerenciamento de projetos. Pela minha experiência, essa é a vantagem mais solicitada no que se refere a sistemas de EPM, mas é também praticamente a última vantagem que eu posso oferecer. Isso ocorre porque o planejamento da capacidade de recursos exige muitos outros elementos para que possa funcionar. Para oferecermos uma projeção de requisitos de recursos versus disponibilidade precisamos primeiro de:

  • Planos de projeto confiáveis

  • Projetos com controle preciso do progresso

  • Alocar todas as tarefas aos recursos

  • Disponibilidade total e precisa de recursos

  • Quantificação e controle de todo o trabalho não relacionado ao projeto

  • Conformidade total por parte dos gerentes de projeto e gerentes de departamento com o trabalho concluído, o trabalho projetado e mudanças de recursos.

Ufa! Não é uma lista pequena, e a cultura corporativa necessária para estar em conformidade com um ambiente desse tipo muitas vezes exige gerenciamento de alterações em grande escala. É hora de voltarmos ao modelo de maturidade do sistema de gerenciamento de projetos para que os clientes possam traçar um mapa do que precisam alcançar.

Não precisa ser uma lista completa, é claro. Podemos facilmente fazer uma terceira coluna e depois uma quarta, mas não fiz isso aqui porque a essa altura a progressão mais comum não é tão clara. Os requisitos de gerenciamento de projeto de cada organização ditarão o interesse em realizar avanços em uma área específica.

Eu prometi no começo deste artigo falar sobre uma mudança que ocorreu nos últimos anos. O modelo que descrevi acima se manteve por bastante tempo, mas, recentemente, o setor de TI começou a se mobilizar em outro sentido, e isso está diretamente relacionado à colaboração.

Houve uma época no setor de softwares de gerenciamento de projetos em que éramos muito centrados em algoritmos. Pensávamos que tudo derivava do método do caminho crítico. Os últimos anos, no entanto, trouxeram algumas alterações. Em primeiro lugar, a disponibilidade das pessoas graças à onipresença da tecnologia da Internet ou de telefonia tornou ainda mais fácil montar sua equipe de projeto e se comunicar com ela. Isso ajudou a mudar quem faz parte de uma equipe de gerenciamento de projeto. Enquanto antes imaginávamos os membros da equipe de projeto como pessoas nas profundezas da organização, trabalhando em uma sala pequena e sem janelas, com mesas ao redor de uma plotadora enorme, agora pensamos em membros da equipe de projeto espalhados por toda a organização.

Esses membros incluem aqueles que estão fazendo o trabalho, é claro, mas também o patrocinador executivo, os gerentes de recursos do departamento, os usuários e o departamento de marketing. Agora é bastante comum ver que a equipe do projeto se estende não apenas para além das paredes do prédio, mas para bem longe da organização em si, incluindo subcontratados, contratadores principais e até mesmo o cliente. Subcontratados sequer precisam estar no mesmo fuso horário ou país. Tudo isso tornou a comunicação um fator de sucesso fundamental para projetos em diversos tipos de indústrias.

Isso fez algumas organizações em setores como os de Pesquisa e Desenvolvimento e TI, por exemplo, se basearem em um modelo de maturidade do sistema de gerenciamento de projetos que progride de forma bem diferente:

Elementos de um sistema de gerenciamento de projetos reordenado

O primeiro passo nessas organizações é criar um plano de comunicação, o que quase sempre se baseia em tecnologias de colaboração como o SharePoint Server. Essas organizações acreditam que, a partir de uma perspectiva centralizada, elas podem obter maiores benefícios através da colaboração e comunicação entre sua equipe de gerenciamento de projeto estendida do que de qualquer planejamento centralizado. A ascensão meteórica da popularidade do SharePoint Server veio mostrar que existe um grande desejo reprimido de colocar as pessoas para trabalharem juntas.

Um plano de comunicação básico normalmente progride para o gerenciamento de documentos, sendo que um desses documentos pode muito bem ser um cronograma de projeto. Isso significa virar o progresso tradicional do gerenciamento de projetos corporativos de ponta-cabeça, mas é fácil ver o quanto isso pode parecer atraente para algumas organizações. Mantenha o controle dos contratos, documentos, emails, reuniões e outras comunicações e a eficiência aumentará muito rapidamente. Perca o controle das comunicações e a eficiência poderá sofrer uma queda grave.

O gerenciamento de documentos está a um passo das questões de gestão e do gerenciamento de alterações, o que, para os setores de TI e Pesquisa e Desenvolvimento, significa gerenciar um dos aspectos mais potencialmente nocivos de um projeto.

Obviamente, quadros de horários vêm em seguida. Na verdade, às vezes os quadros de horários vêm antes. Quando nossa organização começou a trabalhar com quadros de horários com nosso produto TimeControl, estávamos convencidos de que as organizações que precisavam de quadros de horários como os nossos eram aquelas que já estavam maduras o suficiente em seus processos de planejamento e controle para poderem se beneficiar deles. Você pode imaginar nossa surpresa quando descobrimos que muitas organizações queriam implantar um quadro de horários corporativo antes mesmo de implantar um sistema de gerenciamento de projetos corporativos. Quando você analisa os desafios de gerenciamento de alterações de cada uma delas, é fácil entender por quê. A maioria dos usuários adotará um quadro de horários a contragosto, mas sem demora. Fazer uma organização com 1.000 pessoas aceitar um sistema de quadros de horários centralizado é uma questão de semanas. Fazer com que esses mesmos 1.000 usuários aceitem um sistema de gerenciamento de projetos centralizado pode levar meses, e até alguns anos. Portanto, mesmo que o planejamento centralizado não esteja estabelecido, a organização ainda poderá obter grandes benefícios dos dados de um quadro de horários centralizado.

Por fim, essas organizações voltam sua atenção para o exercício de planejamento do projeto principal. Isso não quer dizer que elas não tenham feito planejamentos de projeto até o momento, mas que esse processo não têm sido altamente centralizado.

Assim como o primeiro modelo de maturidade do sistema de gerenciamento de projetos, cada um desses elementos também pode conter tópicos avançados.

Planos de comunicação geralmente evoluem para sistemas de comunicação mais integrados, incluindo mensagens instantâneas, integração de email e muito mais.

O gerenciamento de documentos muitas vezes evolui para o gerenciamento do fluxo de trabalho e para a integração de formulários.

O gerenciamento de problemas geralmente evolui para o gerenciamento de listas de todos os tipos e para um processo integrado de gerenciamento de alterações.

Quadros de horários evoluem dos quadros de horários de tarefas para vínculos com o Financeiro, folhas de pagamentos, RH e, em última instância, vinculam-se de volta ao sistema de gerenciamento de projeto corporativo para dados de controle que podem ser auditados.

Planejamento e gerenciamento de recursos tendem a evoluir como meu modelo clássico de maturidade do sistema de gerenciamento de projetos.

Não existe maneira “certa” de utilizar mais a fundo o seu sistema de gerenciamento de projetos, da mesma forma que não existe uma maneira “errada”. Como eu já disse outras vezes nesta coluna, o mais importante é que você examine primeiro o que precisa alcançar para sua organização se tornar mais eficaz e, a partir da daí, desenvolver a solução para este desafio. O fundamental é saber que você possui os blocos de construção dos elementos básicos antes de começar a construir algo mais avançado. O que sempre digo é que precisamos dominar o básico do gerenciamento de projetos antes de partirmos para o gerenciamento de projetos especializado.

Lembre-se de que a aplicação de um sistema de gerenciamento de projetos é apenas um aspecto de uma solução possível, e cabe a você decidir o nível de “maturidade” que precisa ter, e em que áreas, para tornar o gerenciamento dos seus projetos mais eficaz.

Sobre o autor

Chris Vandersluis é presidente e fundador da HMS Software, com base em Montreal, Canadá, um parceiro certificado da Microsoft. Ele é formado em Economia pela McGill University e tem mais de 30 anos de experiência em automação de sistemas de controle de projetos. Membro do Project Management Institute (PMI), ele participou da fundação dos capítulos de Montreal, Toronto e Quebec do Microsoft Project Users Group (MPUG). As publicações para as quais Chris já escreveu incluem a Fortune, a Heavy Construction News, a Computing Canada e a PMNetwork, além de ser colunista regular da Project Times. Professor de Gerenciamento Avançado de Projetos na McGill University, frequentemente dá palestras sobre as funções da associação de gerenciamento de projetos na América do Norte e no mundo. A HMS Software é a fornecedora do sistema TimeControl de controle de horas orientado para projetos e tem sido Parceira de Soluções de Projetos da Microsoft desde 1995.

Chris Vandersluis pode ser contatado pelo email: chris.vandersluis@hms.ca.

Se quiser ler mais artigos relacionados a Gerenciamento de projetos corporativos (EPM) de Chris Vandersluis, consulte o site da HMS (http://www.epmguidance.com/?page_id=39).

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×