Resposta direta

Os resultados de um PMaaS devem ser medidos em quatro níveis diferentes:

  1. qualidade do serviço: o fornecedor mobilizou e manteve a capacidade de gestão combinada?
  2. efetividade da gestão: planos, riscos, mudanças, decisões e controles passaram a funcionar melhor?
  3. desempenho do projeto: a iniciativa ganhou previsibilidade, fluxo, qualidade e capacidade de entrega?
  4. resultado para o negócio: as entregas foram adotadas e contribuíram para benefícios verificáveis?

O ROI financeiro de PMaaS só deve ser calculado quando existirem:

  • linha de base confiável;
  • benefício financeiro realizado ou evitado com evidência;
  • investimento total comparável;
  • período de análise definido;
  • regra de atribuição que separe a contribuição do serviço de outros fatores;
  • validação das áreas responsáveis pelos números.

Antes disso, a empresa pode medir valor observável por indicadores como:

  • confiabilidade dos marcos;
  • estabilidade das previsões;
  • decisões críticas tomadas no prazo;
  • idade dos impedimentos;
  • riscos críticos com resposta ativa;
  • mudanças analisadas antes da execução;
  • retrabalho;
  • aceite na primeira submissão;
  • prontidão para implantação;
  • adoção da solução;
  • benefícios habilitados e realizados.

Em uma frase:

Plano atualizado prova atividade. Decisão tomada prova gestão. Entrega aceita prova resultado do projeto. Benefício realizado prova valor para o negócio. Não trate essas quatro evidências como se fossem iguais.

Por que medir o valor de um PMaaS é difícil?

O PMaaS assume responsabilidades de gerenciamento sobre um projeto ou programa específico. Ele pode organizar o plano, integrar áreas e fornecedores, preparar decisões, tratar riscos e mudanças, coordenar entregas e conduzir a iniciativa até o encerramento ou a transição.

Mas um serviço de gestão não trabalha sozinho.

O desempenho também depende de:

  • patrocínio executivo;
  • disponibilidade das equipes;
  • qualidade da execução técnica;
  • decisões do cliente;
  • capacidade dos fornecedores;
  • estabilidade do escopo;
  • condições contratuais;
  • eventos externos;
  • participação dos usuários;
  • prontidão da operação;
  • adoção da mudança;
  • permanência da justificativa empresarial.

Se o projeto atrasar, isso não prova automaticamente que o PMaaS falhou. O serviço pode ter produzido uma previsão confiável, antecipado a exposição, recomendado alternativas e escalado a decisão enquanto a organização optou por não liberar a capacidade necessária.

O contrário também é verdadeiro. Um projeto pode cumprir a data por esforço extraordinário, horas adicionais, redução silenciosa de escopo ou aceitação de riscos não comunicados. Cumprir um marco, isoladamente, não prova que a gestão foi saudável.

Por isso, medir PMaaS apenas por prazo, orçamento ou satisfação gera uma conclusão incompleta.

Resultado do PMaaS não é igual ao resultado do projeto

Essa separação precisa existir desde o contrato.

Resultado do serviço

Mostra se a capacidade de gestão foi mobilizada e operada conforme as responsabilidades combinadas.

Exemplos:

  • plano integrado mantido;
  • previsões atualizadas com evidências;
  • riscos e problemas tratados;
  • mudanças submetidas ao fluxo correto;
  • decisões preparadas e escaladas;
  • fóruns realizados com consequência;
  • registros preservados;
  • cobertura e continuidade mantidas.

Resultado da gestão

Mostra se os mecanismos gerenciais estão melhorando a coordenação e a capacidade de decidir.

Exemplos:

  • menor tempo de decisão;
  • menos bloqueios envelhecidos;
  • maior confiabilidade dos marcos;
  • dependências críticas com responsável;
  • menor execução de mudanças sem análise;
  • riscos identificados antes do impacto;
  • melhor integração entre cliente e fornecedores.

Resultado do projeto

Mostra se a iniciativa está produzindo e aceitando as entregas previstas dentro dos parâmetros aprovados.

Exemplos:

  • marcos cumpridos;
  • variação de cronograma;
  • variação de orçamento;
  • entregas aceitas;
  • qualidade técnica;
  • retrabalho;
  • prontidão para implantação;
  • transição concluída.

Resultado do negócio

Mostra se as entregas se transformaram em mudança, adoção e benefício.

Exemplos:

  • processo utilizado;
  • tempo operacional reduzido;
  • receita incremental verificada;
  • perda reduzida;
  • despesa eliminada;
  • capacidade convertida em resultado;
  • obrigação regulatória atendida;
  • experiência do cliente melhorada.

O PMI trata a realização de benefícios como um caminho que conecta estratégia, entregas, resultados e valor. A APM também diferencia sucesso da entrega e realização de benefícios, que pode continuar depois do encerramento do projeto.

A cadeia de evidências do valor de PMaaS

Exemplos ilustrativos. Dados fictícios utilizados apenas para demonstração.

Uma forma prática de impedir conclusões exageradas é conectar a atuação do serviço em uma cadeia causal.

Atividade do PMaaS → saída de gestão → mudança de comportamento → efeito no projeto → benefício para o negócio

Exemplo 1: decisão sobre escopo

Camada Evidência
Atividade Consolidar opções, impactos e recomendação
Saída Pacote de decisão apresentado ao patrocinador
Mudança de comportamento Decisão ocorre antes da janela crítica
Efeito no projeto Equipes deixam de trabalhar com premissas incompatíveis
Benefício possível Retrabalho ou extensão pode ser evitado

Exemplo 2: risco de migração

Camada Evidência
Atividade Identificar risco, causa, gatilho e resposta
Saída Plano de mitigação com responsável e prazo
Mudança de comportamento Testes e saneamento começam antes da migração final
Efeito no projeto Taxa de rejeição diminui antes da implantação
Benefício possível Interrupção operacional pode ser reduzida ou evitada

Exemplo 3: integração dos fornecedores

Camada Evidência
Atividade Integrar cronogramas, dependências e critérios de aceite
Saída Plano único com marcos conjuntos
Mudança de comportamento Fornecedores passam a assumir compromissos compatíveis
Efeito no projeto Menos espera e menor retrabalho entre frentes
Benefício possível Capacidade é utilizada com maior eficiência

Exemplo 4: preparação da implantação

Camada Evidência
Atividade Organizar critérios de prontidão, contingência e decisão de entrada
Saída Avaliação objetiva de prontidão
Mudança de comportamento Pendências críticas são resolvidas antes da implantação
Efeito no projeto Entrada em produção ocorre com exposição conhecida e aceita
Benefício possível Menor interrupção, perda ou necessidade de reversão

A cadeia exige prova em cada passagem. Registrar um risco não prova que uma perda foi evitada. Realizar treinamento não prova adoção. Entregar uma funcionalidade não prova benefício.

Os quatro níveis do painel de PMaaS

Nível 1: qualidade do serviço

Responde:

O fornecedor está cumprindo as responsabilidades operacionais que assumiu?

Indicadores possíveis:

  • mobilização concluída conforme o plano;
  • entregáveis de gestão disponíveis no prazo;
  • informações críticas verificadas antes dos fóruns;
  • cumprimento das rotinas combinadas;
  • ocorrências de continuidade;
  • tempo de resposta a inconsistências;
  • registros essenciais atualizados;
  • solicitações fora do escopo;
  • satisfação do patrocinador e das lideranças de frente;
  • ações corretivas do próprio serviço concluídas.

Esse nível avalia a prestação. Ele não prova que o projeto melhorou.

Nível 2: efetividade da gestão

Responde:

A atuação está melhorando coordenação, decisão, antecipação e controle?

Indicadores possíveis:

  • decisões críticas tomadas dentro da janela necessária;
  • idade mediana dos impedimentos;
  • riscos críticos com resposta ativa;
  • ações relevantes vencidas;
  • dependências críticas sem responsável;
  • mudanças executadas sem aprovação;
  • confiabilidade das previsões;
  • exceções identificadas antecipadamente;
  • fóruns que terminaram com decisão, ação ou escalonamento;
  • conflitos entre planos de fornecedores.

Esse é o território mais diretamente influenciado pelo PMaaS.

Nível 3: desempenho do projeto

Responde:

A iniciativa está entregando com maior previsibilidade, qualidade e controle?

Indicadores possíveis:

  • marcos cumpridos no período;
  • variação da previsão de término;
  • entregas aceitas na primeira submissão;
  • proporção de retrabalho;
  • defeitos por severidade;
  • capacidade planejada versus disponível;
  • variação do esforço restante;
  • mudanças acumuladas de escopo;
  • prontidão da implantação;
  • pendências críticas na transição.

PMaaS influencia esse nível, mas não o controla sozinho.

Nível 4: resultado e benefício

Responde:

A entrega foi incorporada e produziu a mudança esperada?

Indicadores possíveis:

  • usuários ou unidades adotantes;
  • utilização real da solução;
  • aderência ao novo processo;
  • tempo para estabilização;
  • indicadores operacionais afetados;
  • benefícios previstos, validados e realizados;
  • efeitos negativos não previstos;
  • sustentabilidade do resultado após a transição.

A responsabilidade principal costuma migrar para o patrocinador, dono do processo ou dono do benefício. O serviço pode organizar e acompanhar, mas não deve se apropriar de resultados produzidos pela operação.

Antes de medir melhoria, forme uma linha de base

Sem condição inicial, a empresa consegue observar movimento, mas não consegue demonstrar melhoria.

A linha de base não precisa ser perfeita. Precisa ser explícita, rastreável e suficientemente confiável para a decisão.

1. Delimite o objeto

Defina:

  • qual projeto ou programa será medido;
  • quais frentes fazem parte;
  • qual período será comparado;
  • quais marcos são realmente críticos;
  • quais fornecedores estão incluídos;
  • qual estágio da iniciativa será observado.

Não compare o conjunto inteiro antes do serviço com apenas uma fase estável depois dele.

2. Registre a situação na entrada

Levante, quando disponíveis:

  • versão aprovada do escopo;
  • linha de base e previsão corrente;
  • marcos vencidos;
  • decisões abertas e idade;
  • impedimentos e duração;
  • riscos e respostas;
  • mudanças solicitadas e executadas;
  • entregas submetidas e aceitas;
  • retrabalho e defeitos;
  • prontidão operacional;
  • indicadores de adoção e benefício.

Quando os dados forem fracos, registre a fragilidade. Melhor admitir que não existe uma linha de base financeira do que construir precisão artificial.

3. Defina a fórmula antes de conhecer o resultado

Para cada indicador, determine:

  • nome;
  • pergunta de gestão;
  • fórmula;
  • unidade;
  • população;
  • fonte;
  • responsável pela coleta;
  • frequência;
  • tolerância;
  • regra de interpretação;
  • limitações.

Mudar a fórmula depois que o resultado aparece compromete a comparação.

4. Registre mudanças de contexto

Durante o período podem ocorrer:

  • troca de patrocinador;
  • redução ou ampliação de escopo;
  • mudança de fornecedor;
  • aumento da equipe;
  • nova obrigação regulatória;
  • interrupção externa;
  • alteração da estratégia;
  • perda de pessoas-chave.

Esses eventos não invalidam automaticamente a medição, mas precisam aparecer na interpretação.

5. Combine quem valida

O fornecedor não deveria validar sozinho o próprio benefício.

Uma divisão possível é:

Informação Responsável primário pela validação
Qualidade do serviço Gestor do contrato e patrocinador
Plano, risco, decisão e mudança PMaaS e responsáveis do cliente
Entrega e aceite Dono da entrega ou área usuária
Dados financeiros Finanças ou controladoria
Adoção Dono do processo ou mudança
Benefício Dono do benefício e patrocinador

Ficha técnica de um indicador de PMaaS

Exemplo ilustrativo. Dados fictícios utilizados apenas para demonstração.

Um indicador sem definição comum vira argumento, não evidência.

Exemplo preenchido: decisões críticas no prazo

Campo Definição
Nome Decisões críticas tomadas no prazo
Pergunta As decisões que afetam marcos estão ocorrendo antes de perder alternativas?
Numerador Decisões críticas concluídas até a data necessária
Denominador Total de decisões críticas com prazo no período
Fórmula Numerador ÷ denominador × 100
Fonte Registro de decisões aprovado
Frequência Semanal, com consolidação mensal
Responsável pelo dado PMaaS
Validação Patrocinador ou autoridade da decisão
Tolerância ilustrativa Verde ≥ 90%; amarelo de 75% a 89%; vermelho < 75%
Ação Escalar decisões vencidas e revisar causa de recorrência
Limitação Não avalia, isoladamente, a qualidade da decisão tomada

As tolerâncias são exemplos. Devem ser ajustadas à criticidade e ao ritmo do projeto.

Doze fórmulas práticas para acompanhar PMaaS

1. Confiabilidade dos marcos

Mede quantos marcos comprometidos para o período foram concluídos conforme a condição aprovada.

Fórmula:

Marcos concluídos no compromisso ÷ marcos comprometidos no período × 100

Não retire do denominador um marco que atrasou. Se houve mudança formal antes do vencimento, registre a nova linha de base separadamente da previsão.

2. Estabilidade da previsão de término

Mede quanto a previsão muda entre ciclos.

Fórmula:

Data prevista atual − data prevista no ciclo anterior

Pode ser expressa em dias. Mudança frequente sinaliza baixa confiabilidade, mesmo que a data final ainda não tenha sido ultrapassada.

3. Precisão da previsão

Compara a previsão registrada em um ponto anterior com o resultado real.

Fórmula:

|Data real − data prevista no ponto de controle|

É importante definir o horizonte. Uma previsão feita dois dias antes da entrega não tem o mesmo valor de uma previsão feita sessenta dias antes.

4. Decisões críticas no prazo

Fórmula:

Decisões críticas tomadas até a data necessária ÷ decisões críticas com prazo no período × 100

Uma decisão só entra se possuir responsável, data necessária e consequência do atraso.

5. Idade dos impedimentos

Fórmula:

Soma dos dias em aberto dos impedimentos ÷ quantidade de impedimentos abertos

A mediana pode ser mais representativa quando poucos casos muito antigos distorcem a média.

6. Riscos críticos com resposta ativa

Fórmula:

Riscos críticos com responsável, ação e prazo válidos ÷ total de riscos críticos abertos × 100

Ter um texto no registro não basta. A resposta precisa estar em execução e ser compatível com a exposição.

7. Ações de risco concluídas no prazo

Fórmula:

Ações de resposta concluídas até o prazo ÷ ações de resposta vencidas no período × 100

Esse indicador complementa o anterior. É possível ter respostas formalizadas e nenhuma ação realizada.

8. Mudanças com impacto analisado

Fórmula:

Mudanças decididas com análise integrada ÷ total de mudanças decididas × 100

A análise deve observar, conforme aplicável, escopo, cronograma, orçamento, capacidade, risco, qualidade, contrato e benefício.

9. Aceite na primeira submissão

Fórmula:

Entregas aceitas sem devolução ÷ entregas submetidas para aceite × 100

Defina critérios de aceite antes da submissão. Sem critério, a métrica pode punir a equipe por expectativas descobertas tarde.

10. Proporção de retrabalho

Fórmula:

Esforço aplicado em refazer trabalho ÷ esforço total do período × 100

Classifique a causa. Retrabalho por erro técnico é diferente de retrabalho causado por decisão tardia ou mudança aprovada.

11. Prontidão para implantação

Fórmula:

Critérios obrigatórios de prontidão atendidos ÷ critérios obrigatórios aplicáveis × 100

Alguns critérios podem ser eliminatórios. Nesse caso, uma média alta não autoriza implantação se um item crítico estiver aberto.

12. Realização de benefícios

Fórmula:

Benefício realizado validado ÷ benefício previsto para o mesmo período × 100

Compare períodos equivalentes. Uma meta anual não deve ser usada para julgar o segundo mês de estabilização.

Quantos indicadores usar?

Um projeto não precisa exibir todos os doze indicadores ao patrocinador.

Uma composição prática pode usar:

  • dois indicadores de qualidade do serviço;
  • três de efetividade da gestão;
  • três de desempenho do projeto;
  • um ou dois de adoção e benefício.

O painel executivo pode ter de seis a dez métricas realmente acionáveis. Indicadores adicionais ficam nas rotinas das frentes.

Uma métrica merece espaço quando:

  1. responde a uma pergunta relevante;
  2. possui fonte minimamente confiável;
  3. tem responsável;
  4. possui limite ou interpretação;
  5. leva a uma ação possível.

Se ninguém muda uma decisão diante do resultado, a métrica provavelmente não deveria ocupar o painel principal.

Indicadores que não devem ser usados isoladamente

Percentual concluído

Pode esconder caminho crítico, dependências, qualidade e esforço restante. Um projeto “90% concluído” pode estar longe do aceite.

Semáforo geral

Transformar dezenas de dimensões em uma cor elimina nuance. Use a cor como entrada para investigação, não como conclusão.

Quantidade de reuniões

Mede atividade. Reunião útil termina com decisão, compromisso, escalonamento ou alinhamento necessário.

Quantidade de riscos

Mais riscos registrados pode significar pior exposição ou melhor transparência. Observe criticidade, resposta, tendência e ocorrência.

Satisfação

É importante, mas pode premiar comunicação confortável e penalizar quem comunica problemas reais. Combine percepção com evidências operacionais.

Cumprimento da data

Pode ter sido obtido por redução de escopo, esforço insustentável ou aceite de exposição. Leia junto com qualidade, mudança, capacidade e benefício.

Horas de gestão

Mostram consumo de capacidade. Não mostram que as decisões, previsões ou entregas melhoraram.

Quando é possível calcular o ROI financeiro de PMaaS?

ROI não é sinônimo de melhora percebida.

O cálculo financeiro só se sustenta quando a empresa consegue responder:

  • qual benefício aconteceu;
  • como foi medido;
  • qual era a condição de referência;
  • em que período ocorreu;
  • qual parte pode ser relacionada ao PMaaS;
  • quem validou o valor;
  • qual foi o investimento total do serviço no mesmo período.

Fórmula básica

ROI de PMaaS (%) = (benefício financeiro atribuível ao PMaaS − investimento total do PMaaS) ÷ investimento total do PMaaS × 100

Essa fórmula não deve usar todo o benefício do projeto como se tivesse sido criado pelo gerente.

ROI do PMaaS e ROI do projeto são diferentes

O ROI do projeto compara benefícios do negócio com o investimento total da iniciativa.

O ROI do PMaaS compara apenas o valor incremental razoavelmente atribuível à capacidade de gestão com o investimento no serviço.

Exemplo conceitual:

  • o projeto implanta um canal que produz receita;
  • o PMaaS melhora coordenação e ajuda a antecipar a implantação;
  • a receita total pertence ao projeto e ao negócio;
  • somente a parcela incremental comprovadamente associada à antecipação pode ser considerada na análise do PMaaS;
  • mesmo essa parcela precisa ser ajustada pela contribuição de equipes, patrocinador e fornecedores.

Benefícios financeiros que podem entrar no cálculo

1. Despesa realmente eliminada

Uma atividade, contrato, estrutura ou gasto deixou de existir como consequência verificável da melhoria.

Evidência possível:

  • razão contábil;
  • contrato encerrado;
  • posição não reposta;
  • fatura reduzida;
  • orçamento retirado e não apenas transferido.

2. Extensão contratual evitada

Uma extensão que seria necessária deixou de acontecer porque a iniciativa foi estabilizada ou uma decisão foi antecipada.

Para entrar no ROI, deve existir:

  • cenário de referência documentado;
  • obrigação ou proposta concreta;
  • relação causal defensável;
  • confirmação de que o gasto não ocorreu;
  • atribuição proporcional.

3. Retrabalho convertido em efeito financeiro

Reduzir horas de retrabalho não é automaticamente economia. O efeito financeiro existe quando a redução:

  • elimina horas adicionais pagas;
  • reduz contratação externa;
  • evita extensão de equipe;
  • permite entregar trabalho adicional mensurável;
  • libera capacidade que foi realmente redirecionada e utilizada.

4. Perda ou penalidade evitada

Pode ser considerada quando o evento era suficientemente provável, a exposição estava documentada e a ação contribuiu diretamente para impedir a ocorrência.

Não conte todo risco registrado como valor evitado.

5. Benefício antecipado

Se o resultado do negócio começou antes por causa de uma melhoria demonstrável na execução, a janela adicional pode produzir benefício incremental.

É necessário provar:

  • data contrafactual defensável;
  • data real;
  • benefício por período validado;
  • parcela atribuível ao PMaaS;
  • ausência de dupla contagem com o ROI do projeto.

6. Receita ou margem incremental

Só deve entrar quando a empresa consegue separar o efeito da gestão de fatores como campanha comercial, demanda de mercado, mudança de produto e atuação das equipes.

Na maioria dos casos, atribuir toda receita ao PMaaS seria incorreto.

O que não deve ser monetizado automaticamente

Capacidade liberada

Horas liberadas representam capacidade, não redução financeira. Só existe benefício monetário quando a capacidade é convertida em consequência verificável.

Todo risco mitigado

Exposição não é perda certa. Somar probabilidade multiplicada pelo impacto de todos os riscos tratados e apresentar o total como economia superestima o retorno.

Decisão mais rápida

Tempo menor é um resultado de gestão. Vira benefício financeiro quando reduz uma consequência específica e comprovada.

Projeto verde

Cor de status não possui valor financeiro próprio.

Redução de reuniões

Menos reuniões pode liberar tempo, mas isso não prova redução de despesa nem aumento de produção.

Satisfação das partes interessadas

É uma medida relevante de experiência e confiança. Não deve ser convertida arbitrariamente em dinheiro.

Todo benefício do projeto

O projeto existe por causa de uma estratégia, uma solução, equipes, fornecedores, usuários e decisões. O PMaaS contribui para a gestão dessa transformação. Não é o único produtor do benefício.

Como tratar atribuição sem inventar causalidade

Uma estrutura simples classifica cada resultado em três grupos.

Grupo A: diretamente produzido pelo serviço

Exemplos:

  • plano integrado estabelecido;
  • relatório com previsão verificável;
  • decisão escalada no prazo;
  • risco com resposta estruturada;
  • registro de mudança funcionando;
  • transição documentada.

Esses resultados podem ser atribuídos majoritariamente ao PMaaS, desde que façam parte do escopo.

Grupo B: influenciado pelo serviço

Exemplos:

  • redução de atraso;
  • menor retrabalho;
  • aceite mais rápido;
  • risco que não se materializou;
  • implantação mais estável;
  • benefício iniciado antes.

O PMaaS contribui, mas equipes, decisões e condições externas também atuam. Exige atribuição compartilhada.

Grupo C: predominantemente produzido pelo negócio

Exemplos:

  • adoção sustentada;
  • receita gerada;
  • despesa operacional reduzida;
  • satisfação do cliente final;
  • ganho de participação de mercado;
  • realização de benefício após a transição.

O serviço pode apoiar e acompanhar. A responsabilidade principal pertence ao dono do benefício e à operação.

Cinco perguntas de atribuição

Antes de associar um benefício ao PMaaS, pergunte:

  1. O resultado teria ocorrido sem o serviço?
  2. Qual mecanismo concreto liga a atuação ao resultado?
  3. Que outros fatores contribuíram?
  4. Existe evidência anterior à conclusão, ou a explicação foi criada depois?
  5. Uma área independente valida a conclusão?

Percentuais de atribuição podem ser usados, mas precisam de justificativa documentada. Um número aparentemente preciso não substitui evidência.

Exemplo preenchido: primeiros 90 dias de PMaaS

Exemplo ilustrativo. Os dados não representam um cliente real da ORQENA.

Uma empresa contrata PMaaS para assumir a gestão de uma implantação de ERP com cinco áreas internas e dois fornecedores.

Condição na entrada

Indicador Linha de base
Marcos críticos concluídos no compromisso 43%
Variação acumulada da previsão em oito semanas 31 dias
Decisões críticas vencidas 12
Idade mediana dos impedimentos 17 dias
Riscos críticos com resposta ativa 38%
Mudanças decididas com impacto integrado 45%
Aceite na primeira submissão 56%
Retrabalho sobre o esforço registrado 15%

Também foram identificadas três limitações:

  • dados de esforço incompletos em duas frentes;
  • critérios de aceite diferentes entre cliente e fornecedor;
  • ausência de linha de base para benefícios operacionais.

Ações realizadas

Nos primeiros 90 dias, o serviço:

  1. confirmou o mandato e as alçadas;
  2. consolidou o plano integrado;
  3. separou linha de base, meta e previsão;
  4. estabeleceu registro de decisões;
  5. reorganizou riscos e respostas;
  6. implantou controle de mudanças;
  7. alinhou critérios de aceite;
  8. integrou os dois fornecedores;
  9. criou avaliação de prontidão;
  10. iniciou a linha de base de adoção e benefícios.

Condição após 90 dias

Indicador Linha de base Após 90 dias Leitura inicial
Marcos críticos concluídos no compromisso 43% 76% Melhoria relevante, ainda abaixo da tolerância acordada
Variação da previsão em oito semanas 31 dias 9 dias Previsão mais estável
Decisões críticas vencidas 12 3 Redução, com três temas ainda materiais
Idade mediana dos impedimentos 17 dias 6 dias Fluxo melhorou
Riscos críticos com resposta ativa 38% 87% Controle estabelecido, ações ainda precisam ser concluídas
Mudanças com impacto integrado 45% 93% Processo estabilizado
Aceite na primeira submissão 56% 79% Critérios mais claros e menor devolução
Retrabalho sobre o esforço registrado 15% 9% Tendência positiva, com qualidade de dados ainda desigual

O que pode ser afirmado

  • a operação de gestão foi estabelecida;
  • decisões e impedimentos estão fluindo mais rápido;
  • previsões ficaram mais estáveis;
  • riscos e mudanças passaram a ter tratamento mais consistente;
  • aceite e retrabalho apresentam melhora observável;
  • ainda existem desvios que exigem ação.

O que não pode ser afirmado

  • que o PMaaS produziu sozinho todas as melhorias;
  • que o projeto cumprirá necessariamente a data final;
  • que todo retrabalho reduzido virou resultado financeiro;
  • que riscos não ocorridos equivalem a perdas evitadas;
  • que benefícios de negócio já foram realizados;
  • que existe ROI financeiro comprovado após 90 dias.

Decisão executiva após 90 dias

A recomendação seria manter o serviço e concentrar o ciclo seguinte em:

  • três decisões críticas vencidas;
  • marcos ainda abaixo da tolerância;
  • critérios de prontidão para migração;
  • qualidade dos dados de esforço;
  • linha de base de adoção;
  • identificação de benefícios financeiros que possam ser validados posteriormente.

Esse exemplo mostra um ponto importante: reconhecer a ausência de ROI comprovado não significa ausência de valor. Significa que a evidência disponível ainda sustenta resultados operacionais, não uma conclusão financeira.

Como construir o cálculo quando os dados estiverem prontos

Use uma tabela de evidências antes da fórmula final.

Benefício candidato Condição de referência Resultado observado Evidência Outros contribuintes Parcela atribuível Validador
Extensão evitada Extensão formalmente prevista Extensão não contratada Plano, decisão e documento contratual Equipes e fornecedor Percentual justificado Finanças e patrocinador
Retrabalho reduzido Taxa e esforço históricos Redução sustentada Apontamento e causa Equipes técnicas Apenas efeito convertível Gestor e controladoria
Benefício antecipado Data contrafactual validada Operação iniciou antes Indicador operacional Produto, operação e fornecedor Parcela incremental Dono do benefício
Perda evitada Exposição documentada Evento impedido Risco, ação e evidência Áreas responsáveis Probabilidade e contribuição revisadas Riscos e finanças

Depois:

  1. confirme apenas os benefícios realizados ou evitados com evidência;
  2. remova sobreposições;
  3. aplique a parcela atribuível;
  4. some os benefícios atribuíveis do mesmo período;
  5. compare com o investimento total do PMaaS;
  6. registre premissas e limitações;
  7. submeta o cálculo à validação independente.

Se os dados não permitem esse processo, não apresente ROI. Use o painel de valor observável até formar evidências melhores.

Avaliação em 30, 60, 90 e 180 dias

Dias 1 a 30: estabelecer verdade operacional

Foco:

  • compreender objetivo e estágio;
  • verificar informações;
  • confirmar responsabilidades;
  • formar linha de base;
  • identificar riscos e decisões urgentes;
  • estabilizar controles mínimos.

Pergunta executiva:

Agora conseguimos explicar a condição real do projeto e o que precisa acontecer em seguida?

Dias 31 a 60: testar o sistema de gestão

Foco:

  • testar previsões;
  • observar decisões;
  • reduzir impedimentos antigos;
  • acompanhar respostas a riscos;
  • verificar adesão aos controles;
  • corrigir excesso ou ausência de ritos.

Pergunta executiva:

A gestão está mudando o comportamento ou apenas produzindo documentos novos?

Dias 61 a 90: verificar efeito no projeto

Foco:

  • confiabilidade dos marcos;
  • qualidade e aceite;
  • retrabalho;
  • estabilidade do plano;
  • prontidão das próximas etapas;
  • causas que permanecem fora da influência do serviço.

Pergunta executiva:

A iniciativa está mais previsível e os desvios estão sendo tratados antes de comprometer o resultado?

Dias 91 a 180: validar sustentação e benefícios

Foco:

  • sustentabilidade das melhorias;
  • preparação da implantação;
  • adoção;
  • indicadores operacionais;
  • benefícios validados;
  • evidências financeiras;
  • transição ou continuidade.

Pergunta executiva:

O resultado se sustenta e já existe evidência suficiente para demonstrar valor empresarial ou ROI?

Os períodos são referências. Projetos curtos ou críticos podem exigir ciclos menores.

Quando manter, corrigir, ampliar, transferir ou encerrar

Manter

Indicado quando:

  • controles estão funcionando;
  • gestão melhora decisões e previsões;
  • responsabilidades estão claras;
  • o projeto ainda exige capacidade externa;
  • riscos e entregas justificam continuidade.

Corrigir

Indicado quando:

  • atividades são executadas, mas não produzem consequência;
  • existem métricas sem decisão;
  • patrocinador não recebe recomendações claras;
  • escopo do serviço e expectativa divergem;
  • qualidade varia entre frentes;
  • dados continuam pouco confiáveis.

A correção pode envolver método, equipe, cadência, responsabilidades ou interação com o cliente.

Ampliar

Indicado quando:

  • a capacidade demonstrou valor em um escopo focal;
  • novas frentes passaram a depender da gestão integrada;
  • a implantação exige cobertura adicional;
  • o programa ganhou complexidade;
  • a ampliação possui resultado e responsabilidade claros.

Não amplie apenas porque o fornecedor está disponível.

Transferir

Indicado quando:

  • o projeto entrou em fase estável;
  • existe sucessor preparado;
  • controles e registros estão organizados;
  • responsabilidades podem ser internalizadas;
  • o risco de transição é aceitável.

Um bom PMaaS não deve criar dependência desnecessária.

Encerrar

Indicado quando:

  • o projeto terminou;
  • a iniciativa perdeu justificativa;
  • a capacidade interna assumiu a gestão;
  • o serviço não corrige falhas relevantes;
  • o cliente não fornece condições essenciais;
  • outro modelo passou a ser mais adequado.

Encerrar um projeto que perdeu valor pode ser um resultado positivo da gestão. Manter trabalho sem justificativa apenas para preservar indicadores seria fracasso de governança.

Responsabilidades do cliente na medição

PMaaS não consegue demonstrar valor sozinho.

O cliente precisa:

  • confirmar objetivos e critérios de sucesso;
  • fornecer dados e acessos;
  • validar a linha de base;
  • nomear patrocinador e donos de benefícios;
  • tomar decisões;
  • registrar mudanças de contexto;
  • disponibilizar informações financeiras;
  • validar aceite, adoção e benefício;
  • permitir que problemas sejam comunicados sem punição;
  • revisar resultados com honestidade.

Se a empresa recompensa projetos sempre verdes, o serviço aprenderá a suavizar a realidade. Se premia previsões confiáveis e decisões antecipadas, a gestão terá espaço para funcionar.

Doze erros ao medir resultados de PMaaS

1. Medir sem linha de base

Sem referência, não existe comparação defensável.

2. Confundir atividade com resultado

Relatórios e reuniões são meios. Decisões, previsões e entregas são consequências.

3. Usar apenas prazo e orçamento

Esses resultados dependem de vários participantes e podem esconder redução de escopo, qualidade ou benefício.

4. Atribuir todo sucesso ao fornecedor

O projeto é produzido por um sistema de pessoas, decisões e capacidades.

5. Atribuir todo desvio ao fornecedor

Uma gestão competente não controla recursos, mercado ou decisões reservadas ao cliente.

6. Monetizar toda hora liberada

Capacidade só vira benefício financeiro quando é convertida em efeito real.

7. Somar riscos como perdas evitadas

Risco possui incerteza. Registro e mitigação não provam que todo impacto aconteceria.

8. Alterar fórmulas durante a medição

Mudanças podem ser necessárias, mas precisam ser registradas e impedir comparações indevidas.

9. Criar métricas demais

Painel extenso dispersa atenção e aumenta esforço de coleta sem melhorar decisão.

10. Ignorar qualidade dos dados

Uma casa decimal não corrige uma fonte incompleta.

11. Punir transparência

Se comunicar risco piora a avaliação, o sistema incentivará ocultação.

12. Calcular ROI antes da realização do benefício

Previsão de benefício é parte do caso de negócio. ROI realizado exige resultado validado.

Quando um PMaaS está funcionando bem?

Um PMaaS está funcionando quando a empresa consegue observar, de forma sustentada:

  • situação real compreendida;
  • planos integrados e utilizáveis;
  • previsões menos voláteis;
  • riscos e problemas antecipados;
  • decisões chegando à alçada correta;
  • impedimentos tratados antes de envelhecer;
  • mudanças analisadas com consequência;
  • equipes e fornecedores coordenados;
  • critérios de aceite aplicados;
  • implantação preparada;
  • conhecimento preservado;
  • responsabilidades transferidas de forma organizada;
  • benefícios acompanhados sem exagero de atribuição.

Isso não significa ausência de problema. Em projetos críticos, uma boa gestão frequentemente torna os problemas mais visíveis antes de conseguir reduzi-los.

Perguntas frequentes sobre resultados e ROI de PMaaS

Quais são os principais indicadores de PMaaS?

Qualidade do serviço, confiabilidade de marcos, estabilidade de previsão, decisões no prazo, idade de impedimentos, riscos com resposta, mudanças analisadas, aceite, retrabalho, prontidão, adoção e benefícios.

Projeto atrasado significa que o PMaaS falhou?

Não automaticamente. É preciso avaliar a causa, a qualidade da previsão, a atuação do serviço, as decisões do cliente, a execução das equipes e os eventos externos.

Projeto no prazo significa que o PMaaS teve sucesso?

Não sozinho. O prazo pode ter sido mantido com redução de escopo, queda de qualidade, esforço insustentável ou benefício comprometido.

É obrigatório calcular ROI financeiro?

Não. Quando faltam benefícios monetários verificáveis ou atribuição confiável, use indicadores de valor operacional e empresarial sem inventar conversão financeira.

Qual é a fórmula do ROI de PMaaS?

(benefício financeiro atribuível − investimento total do PMaaS) ÷ investimento total do PMaaS × 100.

Todo benefício do projeto entra no ROI do PMaaS?

Não. Apenas a parcela incremental que pode ser relacionada ao serviço com evidência e regra de atribuição.

Horas de retrabalho reduzidas podem entrar?

Somente quando forem convertidas em efeito financeiro ou capacidade produtiva validada. Horas isoladas não equivalem automaticamente a economia.

Risco evitado pode entrar?

Pode, com cautela, quando exposição, probabilidade, resposta, não ocorrência e contribuição estiverem documentadas e validadas. Não conte todos os riscos mitigados.

Quanto tempo leva para medir resultado?

Resultados de gestão podem aparecer nos primeiros ciclos. Desempenho do projeto exige mais tempo. Adoção e benefícios podem surgir após implantação e encerramento.

Quem valida o ROI?

Idealmente, finanças ou controladoria com o patrocinador e o dono do benefício. O fornecedor apresenta evidências, mas não deveria aprovar sozinho seu retorno.

Um PMaaS pode gerar valor ao recomendar o encerramento?

Sim. Evitar continuar uma iniciativa que perdeu justificativa pode proteger capacidade e exposição. O benefício precisa ser medido sem contar como economia tudo o que ainda não havia sido comprometido.

Como comparar PMaaS com gerente terceirizado?

Compare responsabilidade, método, supervisão, continuidade, entregáveis e resultado contratado para diferenciar PMaaS de uma simples alocação profissional.

Conclusão

Medir PMaaS exige mais rigor do que verificar se relatórios foram entregues ou se a data final continua verde.

Uma avaliação útil separa quatro níveis:

  1. qualidade do serviço;
  2. efetividade da gestão;
  3. desempenho do projeto;
  4. resultado para o negócio.

O ROI financeiro aparece apenas quando a última camada possui evidências monetárias, período comparável e atribuição defensável.

Antes disso, o valor pode ser observado em decisões mais rápidas, riscos tratados, previsões confiáveis, menor retrabalho, aceite melhor, implantação preparada e conhecimento preservado.

O PMaaS não deve receber crédito por tudo o que deu certo nem culpa por tudo o que deu errado. Deve ser avaliado pelo que assumiu, pelo que influenciou e pelas evidências que consegue sustentar.

Se sua empresa precisa estabelecer uma linha de base e medir a gestão de uma iniciativa crítica, conheça o PMaaS da ORQENA ou converse com a ORQENA.