Migração de recursos: planejamento de capacidade a partir do Microsoft Project

O valor do Project Server, para os PMOs que o operam bem, raramente está nos planos de projeto em si. Estava na camada operacional por baixo: um único pool de recursos da organização do qual todo projeto se servia, apontamentos de horas com custo que alimentavam o faturamento e o reconhecimento de receita, exceções de calendário que se propagavam sozinhas e visões entre projetos com as quais os gestores de recursos tomavam decisões semanais de alocação sobre dados reais. É essa camada operacional que está em risco. Os planos migram. A camada operacional, muitas vezes, não.

Três modos de falha aparecem sempre que os PMOs subestimam isso:

• A armadilha do "a gente adiciona os recursos depois". Uma equipe migra os planos de projeto direitinho e deixa o pool de recursos para o sprint seguinte. Quando chega a hora, os donos de cada projeto já criaram recursos duplicados nos seus projetos, e o gestor de recursos perdeu a fonte única da verdade que fazia as visões de capacidade entre projetos funcionarem.
• A armadilha do "taxas de custo não são críticas para a entrada em produção". As taxas padrão ficam para uma limpeza na fase 2. Dois meses depois, o Financeiro descobre que o fechamento mensal exige dados de apontamentos com custo que já não existem na nova plataforma, porque as taxas não estavam carregadas no momento do lançamento das horas. Os dados não podem ser reconstruídos depois; o reconhecimento de receita trava.
• A armadilha do "o Planner Premium vai dar conta". Um PMO supõe que o produto em nuvem da Microsoft cobre os mesmos casos de uso. Para a modelagem de recursos, não cobre. O Planner Premium não traz pool de recursos da organização, nem apontamentos com custo, nem visão de recursos entre projetos. Descobrir isso depois da migração é tarde demais.

O motivo estrutural das três: o modelo de recursos é a parte do Project Server menos visível numa demonstração rápida e a menos coberta nas listas de comparação dos fornecedores. Planos de projeto, Gantts e painéis rendem boas demonstrações. Pools de recursos da organização, não. Por isso os compradores dão pouco peso à cobertura do modelo de recursos na escolha da plataforma e descobrem a lacuna em produção. Este guia apresenta primeiro o modelo, antes da tática de migração, partindo do princípio de que a maior decisão é qual plataforma de destino você escolhe.

Antes de decidir o que migrar, faça o inventário do que você tem. O modelo de recursos do Project Server tem seis camadas, e cada uma migra de um jeito:

Nem todo PMO usa todas as camadas. A pergunta certa do inventário é "em quais delas a nossa equipe realmente se apoia para decidir?". Se você não usa apontamentos com custo, a camada das tabelas de taxas é decorativa; dá para deixá-la de fora sem consequência. Se não usa genéricos para modelar a demanda, pode juntá-los. Se usa, essa capacidade é inegociável na plataforma de destino.

Faça o inventário antes de comparar plataformas. O resultado dele é uma lista de capacidades obrigatórias para a plataforma de destino, e essa lista molda o resto da migração. A próxima seção supõe que você já tem essa lista em mãos.

As comparações de plataformas se estreitam quando você filtra pela cobertura do modelo de recursos. Este é o quadro honesto, organizado pelas seis camadas acima. Sim, parcial ou não para cada uma:

O produto em nuvem da Microsoft (Planner Premium / Project for the Web, o mesmo produto sob rótulos de SKU diferentes) deixa de fora quase todo o modelo de recursos. É uma escolha deliberada de posicionamento: é uma ferramenta de tarefas de equipe com uma camada de projeto, não uma plataforma de PMO. PMOs que usam a sério o modelo de recursos do Project Server não conseguem substituí-lo pelo Planner Premium sem perder capacidades importantes.

O módulo Resource Management do Smartsheet e o Workfront mantêm o conceito de pool da organização. Eles diferem nos detalhes: o Smartsheet RM é um SKU separado e acrescenta um custo por licença considerável; o pool do Workfront é forte, mas o preço por licença é o mais alto dos quatro. O Onplana não tem um pool de recursos separado: cada pessoa é um membro da organização, e o modelo de recursos é a capacidade semanal dessa pessoa em todos os projetos (a partir do plano Professional), taxas em três níveis (pessoa, função, padrão da organização) e calendários de trabalho com exceções nomeadas, sem complemento pago. Não há recursos genéricos, nem calendários por pessoa, nem RBS formal. O preço começa em US$ 12 por licença por mês (Professional). A comparação honesta com o Planner Premium está na nossa página de comparação com o Planner.

Há outra dimensão difícil de pôr numa tabela: a qualidade da visão de capacidade entre projetos varia muito entre plataformas, mesmo quando a função básica existe. Algumas mostram só alocações diretas em tarefas; outras incluem consolidações de subprojetos; outras incluem a alocação de marcadores genéricos. Se o seu gestor de recursos toma decisões semanais de alocação com essa visão, faça uma comparação lado a lado durante a avaliação com os 25 recursos com mais horas alocadas.

Antes de exportar qualquer coisa, monte um inventário completo do modelo de recursos. É um inventário diferente do da lista de projetos: aquele cataloga projetos; este cataloga a camada de recursos por baixo deles. A entrega é um Relatório de Prontidão da Migração de Recursos que lista cada elemento de recursos, onde está hoje, para onde vai e quem é responsável pela mudança.

1. Lista de recursos com atributos. Exporte o pool completo de recursos da organização com nome, tipo (nominal/genérico/custo), e-mail (para os nominais), unidades máximas, taxa padrão, função/cargo e caminho na RBS. O endpoint OData /Resources é a fonte de referência; o Reporting Database tem mais campos derivados, mas só no Project Server local.
2. Tabelas de taxas de custo. O Microsoft Project aceita até 5 taxas de custo por recurso (taxa A a taxa E) com intervalos de datas de vigência. Exporte cada nível de taxa e cada linha de data de vigência. Se o seu PMO usa só a taxa A, dá para ignorar B–E, mas confirme que é mesmo assim antes de supor.
3. Exceções de calendário. Para cada recurso, exporte a lista de exceções de calendário com nome, intervalo de datas e horário alterado. Se a sua plataforma de destino não preserva exceções nomeadas, registre os nomes num CSV complementar para que o motivo ("Semana do congresso", "Recesso de fim de ano") sobreviva.
4. Hierarquia da RBS. Exporte a estrutura analítica de recursos: cada nó, os vínculos pai-filho e os recursos ligados a cada nó. É a hierarquia que permite aos gestores de recursos filtrar as visões de capacidade pela sua estrutura de reporte.
5. Alocações ativas. Tire um retrato de cada alocação ativa em cada projeto ativo: qual recurso, qual projeto, qual tarefa, horas alocadas, horas reais, início e término previstos. É a base da validação; depois da migração você vai comparar a alocação na origem e no destino.
6. Campos personalizados de recursos. Se o seu PMO definiu Enterprise Custom Fields nos recursos (nível de credencial de segurança, indicador de faturável, tipo de contrato), exporte-os junto com a lista de recursos. Algumas plataformas de destino vão modelá-los como campos nativos, outras como campos personalizados, outras não vão aceitá-los; isso define depois o mapeamento de campos.

O Relatório de Prontidão pronto é a base do resto da migração. Para conferir a qualidade da exportação antes de se comprometer, passe um pool de amostra pela ferramenta de prévia da migração: envie uma fatia representativa do pool de recursos e veja exatamente quais campos, taxas e exceções passam sem problema.

Cinco fases, cada uma com uma entrega e um ponto de decisão de seguir ou não. O tempo total costuma ser de 3–5 semanas para um pool de 100–250 recursos, mais se houver tabelas de taxas de custo muito personalizadas ou uma RBS grande.

Fase 1: Inventário e decisões (1 semana)

Conclua o inventário prévio acima e então decida a plataforma conforme as camadas do modelo de recursos que são inegociáveis para a sua equipe. Documente a decisão com os motivos; é a seção que você vai reler quando alguém perguntar por que a plataforma escolhida não tem a função X.

• Fazer o inventário no locatário em uso
• Pontuar cada plataforma de destino contra a sua lista de camadas obrigatórias
• Escolher o destino e documentar os motivos
• Obter a aprovação da liderança do PMO para a plataforma escolhida

Ponto de decisão: Relatório de Prontidão assinado; plataforma de destino escolhida.

Fase 2: Exportar o pool (2–3 dias)

Exporte do Project Server enquanto ele ainda está no ar e depois confira se a exportação contém cada camada abaixo. Não conte com exportações de arquivos .mpp para o pool de recursos; elas trazem só alocações de recursos locais do projeto, não o pool da organização com as taxas, os calendários e a RBS.

• A lista de recursos, de /Resources
• As exceções de calendário, de /Resources/Calendars
• As tabelas de taxas de custo (ou o Reporting DB, no local)
• A RBS, dos endpoints da API SOAP, que não têm equivalente em OData
• As alocações ativas, de /Assignments
• Contagens que batem com o Relatório de Prontidão

Ponto de decisão: a contagem exportada bate com a do Relatório de Prontidão em cada camada.

Fase 3: Remodelar no destino (3–7 dias)

Importe o pool na plataforma de destino e então trate, camada por camada, as lacunas de transposição que a comparação de plataformas revelou. Genéricos que não passam são remodelados como marcadores nominais. Nomes de exceções de calendário que não passam são arquivados. Campos personalizados de recursos são mapeados para campos nativos ou para definições de campos personalizados no destino.

• Importar a lista de recursos (importação em massa ou API do destino)
• Recriar a hierarquia da RBS e ligar os recursos aos nós
• Carregar as taxas padrão e as tabelas de taxas de custo antes de qualquer dado de alocação
• Aplicar as exceções de calendário por recurso
• Transpor os recursos genéricos conforme o modelo da plataforma
• Mapear os campos personalizados de recursos

Ponto de decisão: contagem do pool, hierarquia da RBS e contagem de tabelas de taxas batem com a origem.

Fase 4: Alocar e validar (1 semana)

Migre as alocações de tarefas projeto a projeto, em ondas agrupadas pela equipe responsável. Depois de cada onda, a equipe que recebe valida em até 48 horas a alocação no destino contra a origem para os seus projetos. Não avance até a onda validar sem diferenças; perseguir desvios de alocação acumulados em muitos projetos é bem mais difícil do que corrigi-los projeto a projeto.

• Migrar as alocações em ondas de 10–25 projetos
• Diferença de alocação por recurso e por projeto: origem contra destino
• Investigar qualquer variação > 5%
• Conciliar os cálculos de apontamentos com custo numa amostra de apontamentos passados

Ponto de decisão: diferença de alocação por recurso < 5% em todos os projetos.

Fase 5: Visões de capacidade e conciliação (1 semana)

Recrie as visões de capacidade que os gestores de recursos realmente usam e rode-as em paralelo com o Project Server por pelo menos 5 dias úteis. Relatórios diários de diferenças apontam cada lugar em que o cálculo de capacidade da nova plataforma difere do da antiga. Investigue cada diferença. Documente as diferenças reais como limitações conhecidas.

• Reconstruir as 5 principais visões de capacidade no destino
• Gerar relatórios diários de diferenças para os 25 recursos com mais horas alocadas
• Investigar variações > 5%; documentar as diferenças reais de plataforma
• Treinar os gestores de recursos na nova interface das visões de capacidade
• Virada: o destino passa a ser a fonte da verdade, o Project Server fica só leitura

Ponto de decisão: 5 dias úteis seguidos de relatórios diários de diferenças limpos; os gestores de recursos aprovaram a nova interface das visões de capacidade.

Os cinco modos de falha do modelo de recursos que aparecem com mais frequência, com a prevenção de cada um:

O padrão das cinco: cada uma é uma decisão do tipo "a gente resolve depois", barata na hora e cara em produção. O trabalho de conciliação é um dos custos mais subestimados nos orçamentos iniciais; na calculadora de custo de migração ele entra em operação em paralelo.

A fase de validação tem três verificações, e cada uma produz uma evidência. Arquive-as com o Relatório de Prontidão; juntas, elas formam a trilha de auditoria da migração.

1. Conciliação da alocação por recurso. Para os 25 recursos com mais horas alocadas nos próximos 90 dias, compare a alocação na origem e no destino. Tolerância: ±5%. Uma variação maior significa que a migração das alocações perdeu dados ou que o cálculo de capacidade do destino difere estruturalmente do do Project Server. As duas coisas precisam ser investigadas. Evidência: um relatório de diferenças por recurso.
2. Conciliação de uma amostra de apontamentos com custo. Escolha os 10 apontamentos fechados mais recentes de 5 recursos diferentes. Refaça o cálculo de custo no destino com os mesmos lançamentos de horas. Tolerância: ±1% (é dinheiro; a tolerância é mais apertada que a da alocação). Uma variação > 1% indica uma taxa errada, uma exceção de calendário perdida ou as duas coisas. Evidência: os cálculos de custo lado a lado.
3. Paridade das visões de capacidade entre projetos. Reproduza as 3 visões de capacidade que os gestores de recursos mais usam. Compare lado a lado com a última execução do Project Server para o mesmo período. Diferenças na forma como as duas visões classificam a alocação (direta ou de subprojeto, nominal ou genérica) são esperadas. Documente-as como diferenças conhecidas de plataforma no manual pós-migração. Evidência: capturas de tela lado a lado com as diferenças documentadas.

O resultado da fase de validação é um Relatório de Resultado da Migração com o que migrou, o que não migrou e o que está em aberto. Junto com o Relatório de Prontidão da fase 1, os dois documentam a trilha de auditoria completa.

O PMO é dono do manual de migração, mas o modelo de recursos tem consequências que as equipes financeiras descobrem depois da virada se ninguém as levantar antes. Três padrões aparecem em toda migração que envolve recursos com custo, e cada um bate de um jeito diferente dos problemas do lado do PMO.

Três conceitos de taxa que se confundem

O Project Server mantém três taxas diferentes por recurso que soam parecidas e NÃO são intercambiáveis: a taxa padrão (o custo de uma hora interna para modelar a alocação, muitas vezes o custo total da mão de obra), a taxa de custo (a usada para calcular o custo contábil de um apontamento, às vezes dividida nas tabelas de taxas A a E para tipos de atividade diferentes) e a taxa de cobrança (a cobrada do cliente pelas horas faturáveis de um contrato). Alguns PMOs usam uma taxa para os três conceitos; outros, taxas distintas por conceito; outros, níveis de tabelas de taxas dentro de cada conceito.

Antes de exportar, pergunte ao financeiro quais conceitos de taxa ele realmente usa, quais níveis de tabela correspondem a quais atividades e quais campos da plataforma de destino cada taxa preenche. A exportação é uma linha por taxa e por recurso; a importação é uma decisão de mapeamento que determina se os relatórios de reconhecimento de receita do próximo trimestre vão fechar. Um erro comum e recuperável é carregar as taxas de cobrança no campo da taxa de custo. Os apontamentos com custo passam a ser calculados com a taxa de cobrança, os relatórios de resultado mostram custos inflados e a correção é exportar e carregar de novo. Um erro pior e mais difícil de corrigir é carregar as taxas de custo no campo da taxa de cobrança. Faturas emitidas com a taxa errada precisam ser reemitidas, e a conversa de correção com o cliente não sai de graça.

As regras de capitalização não se mudam sozinhas

PMOs em organizações reguladas ou com muito investimento costumam ter políticas de capitalização de mão de obra que dizem "horas de engenharia em projetos capitalizáveis vão para um ativo do balanço em vez de despesa". No Project Server essas regras costumam existir como visões ou relatórios construídos sobre o feed OData, às vezes com um indicador por projeto e outro por tarefa. Nada dessa infraestrutura migra sozinho. Os indicadores são exportados (valores de campos personalizados); as visões e os relatórios, não. O financeiro precisa reconstruir do zero os relatórios de capitalização na nova plataforma, sobre os mesmos dados marcados.

O risco é um trimestre silencioso em que os relatórios de capitalização não foram reconstruídos, horas que deviam ser capitalizadas viraram despesa e o período fecha com números errados. Erros relevantes aqui são um apontamento de controle interno. Peça ao financeiro que trate a reconstrução da capitalização como uma frente paralela à migração, não como um depois, e condicione a virada a pelo menos um período fechado de relatórios de capitalização lado a lado que batam.

Relatórios de utilização faturável precisam de configuração explícita

PMOs de serviços profissionais vivem da utilização faturável (horas faturáveis divididas por horas pagas, por recurso e no total). O Project Server a produz combinando os dados de apontamentos com um indicador de "faturável" no nível da alocação ou da tarefa. O indicador é exportado sem problema; o relatório, não. Como mostra a matriz de comparação acima, o suporte a relatórios nativos de utilização faturável varia conforme a plataforma de destino. O Onplana, o Smartsheet RM e o Workfront entregam o relatório como peça de primeira linha; o Planner Premium da Microsoft não tem conceito de faturável.

Para PMOs que migram para uma plataforma que tem utilização faturável, condicione a virada a um relatório lado a lado das últimas 4 semanas que bata dentro de ±2%. Qualquer variação maior aponta para um erro no mapeamento de taxas, um indicador de faturável ausente ou uma alocação que não migrou. Para PMOs cuja plataforma de destino não tem utilização faturável nativa, planeje levar o retrato OData para uma ferramenta de BI posterior (Power BI, Looker, Sigma) e reconstruir o relatório lá. Em qualquer caso, o financeiro deve aprovar a exatidão do relatório antes de a plataforma antiga ser desligada. Caso contrário, o primeiro fechamento de mês na nova plataforma é quando a lacuna aparece, e esse é o pior momento possível.

Por que o financeiro precisa estar na sala antes da virada

Em toda migração em que o financeiro entrou tarde, os mesmos três problemas se repetem: os mapeamentos de taxas precisam ser refeitos porque o financeiro discordou da leitura do PMO sobre qual taxa é qual; os relatórios de capitalização não foram reconstruídos e o primeiro fechamento trimestral na nova plataforma reportou errado a mão de obra capitalizada; a variação da utilização faturável passou da tolerância do PMO porque o financeiro aplica outras regras. Nenhum é problema de plataforma; todos são falhas de coordenação. A solução é barata: inclua o financeiro como aprovador nomeado na fase 1 (inventário) e na fase 4 (alocar e validar). A aprovação dele fecha o ciclo do mapeamento de taxas, dos relatórios de capitalização e da tolerância da utilização faturável. Sem ela, o PMO entrega a migração e o financeiro descobre o custo semanas depois, quase sempre num fechamento de mês, quase nunca num calendário que permita refazer com calma.

A migração é o evento que dispara tudo; a pergunta de longo prazo é se a prática de planejamento de capacidade do seu PMO continua funcionando na nova plataforma. Quatro hábitos separam as equipes que mantêm o rigor das que se desviam:

• Fonte única da verdade, aplicada. O pool de recursos da organização é a referência; criar recursos locais num projeto é um indicador precoce de desvio. Algumas plataformas permitem bloquear a permissão de criação por projeto. Use-a se existir; se não, faça uma auditoria semanal comparando as listas de recursos de cada projeto com o pool da organização.
• Revisão trimestral de taxas. Taxas padrão que passam 12+ meses sem revisão se afastam do custo total real da mão de obra. Os apontamentos com custo então se afastam da realidade financeira. Defina um ritmo trimestral para revisar as tabelas de taxas e reajustá-las.
• Disciplina com exceções nomeadas. As exceções de calendário se acumulam em silêncio. Um recurso com 30 exceções nomeadas em 3 anos é normal; sem um ritmo de revisão, as exceções se fossilizam. Todo ano, revise a quantidade de exceções por recurso e elimine o que for mais antigo que o prazo de retenção da política.
• Evolução da RBS. A hierarquia de reporte que estava certa na migração vai ficando desatualizada conforme a organização se reestrutura. Planeje uma revisão da RBS a cada 6 meses dentro do ciclo geral de revisão do desenho organizacional, para que o recorte das visões de capacidade continue fazendo sentido.

As perguntas que os PMOs mais fazem sobre a migração do modelo de recursos. O esquema FAQPage completo está nos dados estruturados deste artigo, para que estas perguntas apareçam no recurso "As pessoas também perguntam" do Google.

Expand