White paper EPM: centralizado ou descentralizado?

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). 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 de gerenciamento de projetos centralizado pode não ser a melhor solução.

Para baixar a versão do Word deste white paper, consulte EPM-centralizado ou descentralizado?.

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

EPM: centralizado ou descentralizado?

Sou defensor do Gerenciamento de projetos corporativos desde que entrei na indústria de gerenciamento de projetos no início dos anos 80. Você pode imaginar que eu sempre daria meu voto ao gerenciamento de projetos centralizado, mas nem sempre foi assim. Vamos discutir por alguns instantes apenas o significado de Gerenciamento de projetos corporativos.

EPM pode significar muitas coisas diferentes para pessoas diferentes. Eu já discuti em outros artigos desta coluna como o propósito de uma implantação de EPM pode ser o gerenciamento de documentos para uma organização e agendas integradas para outra. No entanto, a base do Gerenciamento de projetos corporativos é a noção de que as pessoas devem interagir umas com as outras durante o gerenciamento de projetos. Isso significa que o gerente de projetos e/ou a equipe de gerenciamento de projetos não trabalham de forma completamente independente. Mas isso significa que a única maneira de obter essa "interação" é ter um sistema de agendamento do projetos centralizado? Não necessariamente. Para algumas organizações, o desafio do gerenciamento de projetos pode ser uma incapacidade de produzir relatórios resumidos de gerenciamento de projetos para toda a empresa pelo fato de os projetos serem todos gerenciados em uma base ad-hoc. Nesse caso, o EPM pode ser alcançado apenas com o estabelecimento de padrões de projetos que são compartilhados entre todos os responsáveis pelo gerenciamento de projetos. A melhor maneira de conseguir isso pode ser com um pool centralizado de modelos, materiais de treinamento, documentos e padrões de relatório que todos possam usar. Talvez um site simples do SharePoint fosse suficiente.

Para algumas organizações, o desafio do gerenciamento de projetos pode ser agendas pessoais ineficientes devido à falta de comunicação entre os recursos sobre o que eles estão trabalhando e qual será o próximo objetivo. Nesse caso, o EPM pode ser obtido melhorando a comunicação dentro da equipe e entre outras equipes. As ferramentas podem ser tão simples quanto um calendário compartilhado, mensagens instantâneas ou um portal compartilhado no qual as pessoas podem listar quais são suas prioridades.

Em algumas organizações, o desafio do gerenciamento de projeto é apenas conseguir um progresso nos projetos de desenvolvimento de programação. Se esse for o caso, as ferramentas já presentes em produtos como o Visual Studio Team Services podem ser suficientes. É muito comum em projetos de programação perceber que muitas tarefas podem ser concluídas em praticamente qualquer ordem. Portanto, talvez os rigores do Agendamento de caminho crítico não sejam apropriados, dependendo do tipo de desenvolvimento que está sendo realizado.

Lembro que há alguns anos eu trabalhava no departamento de manutenção de uma companhia aérea. A equipe podia escolher sua própria agenda no início do mês, e se isso não fosse coordenado (como era, frequentemente, o caso) havia a possibilidade de um gerente chegar ao turno e descobrir que ninguém estava trabalhando. O desafio de gerenciamento de projeto nesse caso não era "quando o trabalho será concluído?", mas "alguém virá trabalhar?" Nesse caso, o EPM era obtido implementando uma ferramenta de agendamento de turno.

Mesmo quando aplicamos o desafio de EPM a agendas de projeto, não é imediatamente óbvio que a implantação de um sistema de gerenciamento de projeto centralizado seja a única ou a melhor resposta. Vale a pena perguntar que tipo de interação as pessoas da equipe de gerenciamento de projeto precisam estabelecer entre si. Se eles precisam colaborar regularmente para resolver conflitos de recursos, verificar quais outras prioridades estão surgindo na organização ou ver como o andamento de um projeto afetará outro projeto, uma ferramenta como o Project Server faz sentido. Porém, normalmente eu acabo interagindo com organizações que nem mesmo fazem essa pergunta.

Em algumas organizações, encontramos um pequeno número de agendadores e um grande número de recursos. Mesmo em uma organização de grande porte, essa pode ser a estrutura dependendo do setor e do tipo de projetos que estão sendo executados. Há pouco tempo eu participei de uma reunião em uma organização que tinha certeza sobre a escolha da solução para seu desafio de EPM. Eles pediram que eu articulasse a solução, mas, como de costume, eu pedi que primeiro eles articulassem sobre o problema de gerenciamento de projeto.

Quando eles terminaram de descrever o ambiente da empresa em um quadro branco, ficou evidente até mesmo para eles que a solução escolhida não resolveria o problema deles.

Nesse caso, o problema era a falta de informações de progresso dos projetos relatada por um grande grupo de fornecedores. O cliente determinou que o que eles realmente precisavam fazer era impor um tipo de quadro de horários de tempo e de cobrança para seus fornecedores. O Diretor do programa pareceu desanimado. "Nunca vamos conseguir colocar isso nos contratos dos fornecedores", disse. Felizmente, um membro do Departamento financeiro estava presente. "Sabe de uma coisa", essa pessoa respondeu, "já existe uma cláusula que exige o preenchimento de um quadro de horários de nossa escolha no contrato de fornecedores". Problema resolvido.

Falo frequentemente por aqui sobre a ideia de percorrer o problema antes chegar a uma solução, mas essa é uma ideia difícil de adotar. O raciocínio lógico diria que a ordem para determinar uma solução automatizada seria:

  1. Identificar o problema

  2. Definir a solução

  3. Determinar se a solução deve ser automatizada (e, em caso afirmativo, como fazer isso)

Demonstrações automatizadas de solução em sites na Web, vídeos e em qualquer outro lugar fazem com que esqueçamos isso. Não procuramos uma solução a menos que exista algum tipo de problema, é claro. Mas as soluções automatizadas são tão cativantes que acabamos fazendo o seguinte:

  1. Escolhemos a solução automatizada

  2. Transformamos a implantação da solução em problema

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

  4. Tentamos lembrar qual era o problema original

O novo problema se torna, durante algum tempo, a implementação da solução e, então, após semanas, meses ou até mesmo alguns anos alguém da alta administração pergunta quando o problema original será resolvido e todos se olham surpresos. Foi fácil esquecer sobre isso.

Ao longo dos anos, recomendei todos os tipos possíveis de soluções automatizadas. Claro, o Project Server foi uma das opções, mas eu também recomendei uma combinação de Microsoft Project Pro e SharePoint Server. Eu já recomendei o uso de uma combinação do Excel e do Outlook. Eu já recomendei o uso de quadros de horários de terceiros com o Project.

Uma vez recomendei até mesmo um grande quadro branco. Verdade. A organização era uma com a qual eu fazia negócios há anos. A pessoa em questão tinha uma função de corretor de imóveis e precisava renovar financiamentos de longo prazo. Quando eu perguntei qual era o problema, claramente era uma questão de agendamento. A pessoa havia perdido alguns prazos importantes e tinha certeza de que uma ferramenta de gerenciamento de projetos corporativos corrigiria o problema. A organização já havia solicitado a distribuição de relatórios para vários executivos para que não se perdessem os prazos futuros. "Quantos usuários seriam?" Perguntei. "Apenas eu", ele respondeu. "Há quantos projetos desse tipo por vez?", perguntei. "Sete ou oito", ele respondeu. "E quantas dessas metas de prazo você gerencia para cada projeto?". “É muito complicado. Há cerca de seis prazos para cada um deles", ele disse.

Já estava claro para mim que não deveríamos instalar um grande sistema centralizado de EPM para esse pobre colega.

"Por que não colocar apenas um grande quadro branco em sua baia e usar alguns marcadores coloridos para as diferentes metas?", perguntei. "Você poderia usar azul para a primeira, verde para a segunda, vermelho para a última, etc."

Ele fazia anotações, fascinado pelo conceito. Deixei a empresa sabendo que não havia vendido qualquer serviço ou produto naquele dia, mas que havia desapontado a pessoa pelo fato de ela não poder implantar o sistema planejado. No carro, a caminho de casa, meu telefone tocou. Era ele. "Você poderia explicar as cores diferentes para o quadro branco?", ele perguntou.

Descobrir quais problemas você está tentando resolver antes de criar a solução e antes de escolher como automatizar essa solução não apenas economiza seu dinheiro. Também economiza uma quantidade imensa de tempo gasto trabalhando em elementos da organização que não apresentavam problemas que precisassem de solução em primeiro lugar.

Quando os problemas que você está tentando resolver podem ser solucionados com um software centralizado de gerenciamento de projetos corporativos, nada mais será realmente necessário, mas o conhecimento que você terá obtido por articular o problema o ajudará até mesmo nesse caso. 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. Centralizado ou descentralizado? O Gerenciamento de projetos corporativos pode ser realizado com qualquer dos dois.

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 de controle de horas orientado para projetos TimeControl e é 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 de Chris Vandersluis relacionados a Gerenciamento de Projetos Corporativos (EPM), consulte o site sobre diretrizes de Gerenciamento 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.

×