EPM: Centralizado ou descentralizado?

Este artigo faz parte da nossa coleção "From the Trenches". Ele descreve como as organizações precisam entender os problemas que estão tentando resolver ao decidir sobre a implementação de um sistema de gerenciamento de projetos. Às vezes, implantar um sistema centralizado de gerenciamento de projetos pode não ser a melhor resposta.

Para baixar a versão do Word deste artigo, consulte EPM-Centralizado ou Descentralizado?.

Para ver mais artigos, consulte white papers "From the Trenches".

EPM – Centralizado ou Descentralizado?

Sou proponente do Enterprise Project Management desde que entrei pela primeira vez no setor de gerenciamento de projetos no início dos anos 1980. Você pensaria, então, que eu sempre votaria do lado da gestão centralizada do projeto, mas nem sempre é o caso. Vamos discutir por um momento exatamente o que queremos dizer com o Enterprise Project Management.

O EPM pode significar muitas coisas diferentes para pessoas diferentes. Já discuti em outros artigos nesta coluna como o foco de uma implantação do EPM pode ser o gerenciamento de documentos para uma organização e agendas integradas para a próxima. No entanto, o Enterprise Project Management tem em sua essência a noção de que as pessoas devem interagir entre si no exercício de gerenciamento de projetos. Isso significa que o gerenciador de projetos e/ou a equipe de gerenciamento de projetos não funcionam completamente independentemente. Mas isso significa que a única maneira de alcançar essa "interação" é ter um sistema de agendamento de projeto centralizado? Não necessariamente. Para algumas organizações, o desafio de gerenciamento de projetos pode ser uma incapacidade de produzir relatórios de gerenciamento de projetos em toda a empresa, devido a projetos serem todos gerenciados em uma base ad hoc. Nesse caso, o EPM pode ser alcançado apenas por ter padrões de projeto compartilhados entre todos os funcionários de gerenciamento de projetos. Isso pode ser melhor obtido com um pool central de modelos, materiais de treinamento, documentos e padrões de relatório que todos podem usar. Talvez um site simples do SharePoint seja suficiente.

Para algumas organizações, o desafio de gerenciamento de projetos pode ser agendamentos pessoais ineficazes devido à falta de comunicação entre os recursos sobre o que estão trabalhando e em qual é seu próximo foco. Nesse caso, o EPM pode ser alcançado melhorando a comunicação entre equipe e equipe. As ferramentas podem ser tão simples quanto um calendário compartilhado, mensagens instantâneas ou um portal compartilhado onde as pessoas poderiam listar quais são suas prioridades.

Em algumas organizações, o desafio de gerenciamento de projetos está apenas obtendo progresso nos projetos de desenvolvimento de programação. Se esse for o caso, as ferramentas já presentes em um produto como Visual Studio Team Services podem ser suficientes. É bastante comum em projetos de programação descobrir que muitas tarefas podem ser concluídas em quase qualquer ordem, portanto, os rigores do Agendamento de Caminho Crítico podem nem ser apropriados dependendo do tipo de desenvolvimento que está sendo feito.

Lembro-me de alguns anos atrás trabalhando com o departamento de manutenção de uma companhia aérea. Os funcionários foram autorizados a escolher seus próprios horários no início de cada mês e se isso não fosse coordenado (como era frequentemente o caso), era possível chegar para gerenciar um turno apenas para descobrir que ninguém estava trabalhando. Seu desafio de gerenciamento de projetos não era "Quando a obra será concluída?" era "alguém vem trabalhar?" Nesse caso, o EPM foi alcançado implementando uma ferramenta de agendamento de turnos.

Mesmo quando focamos o desafio do EPM para agendamentos de projetos, não é imediatamente óbvio que implantar um sistema centralizado de gerenciamento de projetos é a única ou a melhor resposta. Vale a pena perguntar qual interação o pessoal do gerenciamento de projetos precisa ter entre si. Se eles devem colaborar regularmente para resolver conflitos de recursos, para ver quais outras prioridades na organização estão chegando ou para ver como o progresso de um projeto afetará outro, então olhar para uma ferramenta como o Project Server faz todo o sentido, mas muitas vezes acabo interagindo com organizações que nem sequer fizeram essa pergunta de si mesmas.

Em algumas organizações, encontramos um pequeno número de agendadores e um grande número de recursos. Mesmo em uma organização de bom tamanho, essa pode ser a estrutura dependendo da indústria e do tipo de projetos que estão sendo realizados. Não faz muito tempo eu me encontrei com uma organização que tinha certeza de que eles tinham escolhido a solução certa para o desafio do EPM. Eles me pediram para articular a solução, mas, como de costume, pedi que primeiro articulassem o problema de gerenciamento de projetos.

No momento em que eles terminaram de descrever seu ambiente em um quadro branco era evidente até mesmo para eles que a solução que eles escolheram não iria resolver seu problema.

Nesse caso, o problema foi a falta de progresso do projeto que estava sendo relatado por um grande pool de subcontratados. O cliente determinou que o que eles realmente precisariam fazer seria impor um tipo de tempo e cobrança de folha de tempo em seus subcontratados. O Diretor do Programa foi desencorajado. "Nunca seremos capazes de colocar isso nos contratos subcontratados", disseram eles. Felizmente, um membro do Departamento de Finanças estava presente. "Você sabe", essa pessoa respondeu, "uma cláusula que exige que ela preencha a folha de tempo de nossa escolha já está no contrato de subcontratado." Problema resolvido.

A idéia de passar pelo problema antes de chegar à solução é uma que eu falo muitas vezes por aqui, mas é difícil de adotar. O pensamento lógico ditaria que a ordem de determinar uma solução automatizada seria:

1. Identificar o problema

2. Definir a solução

3. Determinar se deve (e, se for o caso, como) automatizar a solução

Demonstrações de solução automatizadas em sites, vídeos e em outros lugares nos fazem esquecer isso. Não procuramos uma solução, é claro, a menos que tenhamos algum tipo de problema, mas as soluções automatizadas parecem e soam tão convincentes que acabamos fazendo isso:

1. Escolha a solução automatizada

2. Tornar o problema de implantação da solução

3. Resolva esse problema definindo como a ferramenta automatizada pode ser aplicada à solução

4. Tente lembrar qual era o problema original

O novo problema torna-se implantar a solução por um bom tempo e, em seguida, semanas, meses ou até mesmo alguns anos no caminho alguém da alta administração pergunta quando o problema original será resolvido e todos olham uns para os outros bastante surpresos. Foi fácil esquecer.

Ao longo dos anos, recomendei todos os tipos de soluções automatizadas possíveis. O Project Server tem sido uma das opções, é claro, mas também recomendei uma combinação do Microsoft Project Pro e do SharePoint Server. Recomendei usar uma combinação de Excel e Outlook. Recomendei usar folhas de tempo de terceiros com o Project.

Até uma vez recomendei usar um quadro branco grande. Honesto. A organização era uma com a qual eu tinha feito negócios por anos. A pessoa em questão estava em um papel imobiliário e teve que renovar concessões de longo prazo em imóveis. Quando perguntei qual era o problema, era claramente um problema de agendamento. A pessoa havia perdido alguns prazos que eram importantes e tinha certeza de que uma ferramenta de gerenciamento de projetos corporativos corrigiria o problema. A organização já havia pedido que os relatórios fossem distribuídos a vários executivos para que os prazos futuros não fossem perdidos. "Quantos usuários haveria?" Eu perguntei. "Só eu", ele respondeu. "Quantos desses projetos existem por vez?" Perguntei "Sete ou oito", ele respondeu. "E quantos desses marcos de prazo você gerencia para cada projeto "É muito complicado. Há cerca de meia dúzia de prazos para cada um", ele me disse.

Já estava claro para mim que não deveríamos estar instalando um grande sistema centralizado de EPM para este pobre sujeito.

"Por que não colocar uma grande placa branca em seu cubículo e usar alguns marcadores coloridos para os diferentes marcos?" Eu perguntei. "Você poderia usar azul para o primeiro, verde para o segundo, vermelho para o último, etc."

Ele tomou notas abundantes, fascinado pelo conceito. Saí da empresa sabendo que não tinha vendido nenhum serviço ou produto naquele dia, mas que deixei a pessoa desapontada por não poder implantar o sistema que ele tinha previsto. No caminho para casa, meu telefone tocou no carro. Foi ele. "Você poderia explicar as cores diferentes para o quadro branco?", Perguntou ele.

Descobrir quais problemas você está tentando resolver antes de projetar a solução e antes de escolher como automatizar não apenas economiza dinheiro. Ele pode economizar um enorme tempo gasto trabalhando em elementos da organização que não tinham um problema que precisasse ser resolvido em primeiro lugar.

Quando os problemas que você está tentando resolver podem ser melhor resolvidos com o software centralizado de gerenciamento de projetos corporativos, então nada mais realmente fará, mas o foco que você terá obtido ao articular o problema ajudará mesmo lá. Sua equipe de implantação pode criar métricas de sucesso que permitem que o projeto seja declarado um sucesso quando os problemas forem resolvidos. Centralizar ou descentralizar? O Gerenciamento de Projetos Corporativos pode ser alcançado com qualquer um.

Sobre o autor

Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.

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

Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).