É segunda-feira de manhã. Passou a maior parte da sexta-feira a obter actualizações de estado de cinco gestores de projectos diferentes, a reconciliar datas de marcos em três folhas de cálculo e a convencer um relatório do Power BI a fazer algo que não o envergonhe perante a comissão executiva. O painel de controlo tem bom aspeto. Talvez até bom. E, no entanto, a primeira pergunta na reunião é: "Podemos confiar nestes números?"
Esta pergunta é o modo de falha silencioso da maioria das configurações de relatórios da carteira de projectos. Não é um erro técnico. Não são dados em falta. Apenas uma lenta erosão da confiança que faz do seu relatório um ponto de partida para o debate e não uma base para decisões.
Se isto lhe soa familiar, o problema quase de certeza não é o Power BI. É a forma como os relatórios de portefólio estão a ser estruturados - e porque é que as correcções habituais continuam a piorar as coisas.
Porque é que os Relatórios do Portfólio de Projectos falham no Power BI
Há um conjunto específico de condições que transforma um painel de portfólio do Power BI em algo que gera mais perguntas do que respostas. Nenhuma delas é óbvia do exterior, o que é parte da razão pela qual são tão persistentes.
1. O modelo de dados foi concebido para projectos individuais e não para carteiras. A maioria das implementações do Power BI em ambientes de projeto começam com os dados de um projeto - calendário, orçamento, recursos - e depois são expandidos para cobrir um portfólio, empilhando mais do mesmo. O resultado é um relatório que pode mostrar razoavelmente bem o estado de um projeto individual, mas que entra em colapso quando se tenta responder a questões ao nível do portfólio: Que programas estão em risco de falhar os compromissos do terceiro trimestre? Onde é que a derrapagem orçamental se concentra na carteira? O modelo subjacente nunca foi concebido para responder a estas questões e nenhuma quantidade de novas medidas irá corrigir um desajuste estrutural.
2. Os dados de estado chegam de forma inconsistente e ninguém é responsável pelo problema da qualidade. Os relatórios da carteira dependem de os gestores de projeto apresentarem actualizações de estado atempadas e honestas. Na prática, alguns enviam mais cedo, outros enviam mais tarde, outros enviam números optimistas para evitar o escalonamento. O Power BI reporta obedientemente tudo o que recebe. O PMO acaba por ser responsável por um relatório que não controla totalmente - e a liderança acaba por ficar cética em relação a números que podem ou não refletir a realidade. Este não é um problema de pessoas. É um problema de processo e de governação que a camada de relatórios herda.
3. O relatório está a tentar servir demasiados públicos ao mesmo tempo. Os gestores de projectos operacionais precisam de detalhes ao nível das tarefas. Os gestores de programas precisam de acompanhar as etapas. O comité de direção precisa do estado RAG do portfólio e da exposição financeira. Quando um relatório do Power BI tenta fazer tudo isto - normalmente através de um conjunto extenso de páginas e filtros - acaba por não fazer nada disto particularmente bem. Os utilizadores executivos deixam de olhar para ele porque encontrar o que precisam demora demasiado tempo. Os gestores de projeto ignoram-no porque o detalhe não se adequa ao seu trabalho. E o PMO fica a manter um relatório com o qual ninguém está totalmente satisfeito.
O que a maioria das PMOs tenta primeiro - e porque é que não funciona
O instinto, quando um painel de controlo de portefólio não está a funcionar, é acrescentar-lhe mais. Mais filtros. Mais pesquisas. Colunas de status codificadas por cores que passam por três níveis de hierarquia. Formatação condicional que destaca tudo em vermelho até que nada se destaque. Já vi relatórios com dezassete páginas que os executivos navegam pedindo ao PMO para partilhar o seu ecrã e clicar por eles.
A outra ação comum consiste em reconstruir o pipeline de dados. Nova estrutura do SharePoint. Novas transformações do Power Query. Por vezes, um armazém de dados adequado. Ocasionalmente, esta é a decisão certa - mas é um projeto de meses que não resolve a razão pela qual o relatório existente não é fiável. É possível ter dados perfeitamente limpos que alimentam um relatório que, mesmo assim, não é capaz de orientar as decisões.
Há também um padrão que vale a pena mencionar: substituir o Power BI por uma ferramenta PPM dedicada, apenas para acabar com os mesmos problemas de relatórios numa nova interface. A ferramenta muda. As questões subjacentes sobre o que a liderança realmente precisa de ver, e como os dados fluem dos projectos para o portfólio - essas ficam por resolver.
Para ser sincero: não existe uma solução milagrosa. Os problemas dos relatórios de portefólio são sempre, em parte, um problema de dados, em parte um problema de processo e em parte um problema de conceção. Qualquer pessoa que lhe diga o contrário está a simplificar demasiado. Mas a camada de conceção é normalmente a mais rápida de resolver e é quase sempre abordada em último lugar.
O que realmente ajuda: Conceber para a decisão, não para os dados
O quadro mais útil é partir das questões reais do comité de direção - as três ou quatro coisas que precisam de decidir ao saírem de uma reunião - e conceber de trás para a frente a partir daí. Não é "que dados temos", mas "o que é que o proprietário de uma carteira precisa de ver para tomar uma decisão sobre um programa atrasado?"
Na prática, isto significa normalmente uma separação rígida entre a visão executiva e a visão operacional. A camada de direção necessita de agregação ao nível da carteira: estado geral do calendário, exposição orçamental por programa, um sinal claro sobre quais os projectos que são candidatos a escalonamento. Deve poder ser lida em menos de dois minutos sem clicar em nada. O nível operacional - aquele que os gestores de projeto e os chefes de programa realmente utilizam - pode conter os pormenores. Estas são duas audiências diferentes com necessidades diferentes, e tentar servir ambas num único relatório é onde a maioria dos dashboards de portfólio do Power BI correm mal.
As escolhas de visualização são mais importantes do que a maioria dos PMOs se apercebe. Um estado de semáforo que não mostre a tendência - se um projeto acabou de ficar âmbar ou se tem estado âmbar há seis semanas - é menos útil do que parece. Uma visão geral das etapas ao estilo de Gantt que mostre o desvio do calendário em toda a carteira comunica algo que uma tabela de datas não consegue. A escolha do aspeto visual não é uma questão de decoração; é a diferença entre um relatório que induz a uma decisão e um que induz a uma pergunta.
Esta é a área em que os visuais do Power BI criados especificamente para contextos de gestão de projectos fazem uma verdadeira diferença. A LeapLytics constrói visuais personalizados certificados especificamente para este efeito - coisas como Gráficos de Gantt e indicadores de semáforo concebidos para a elaboração de relatórios de carteira, e não adaptados a partir de casos de utilização genéricos de BI. Não resolvem o problema do modelo de dados nem o problema da governação, mas quando a estrutura é correta, tornam os resultados consideravelmente mais legíveis para as pessoas mais importantes.
Antes e depois: O que muda quando o relatório de carteira realmente funciona
Um PMO de infra-estruturas de média dimensão - cerca de 40 projectos activos em quatro programas - chegou a um ponto em que a revisão mensal do seu portfólio demorava três horas em vez de noventa minutos, sobretudo porque cada estado comunicado desencadeava uma discussão de acompanhamento sobre se os números estavam actualizados. Os gestores de projeto enviavam actualizações por e-mail. O PMO estava a atualizar manualmente um ficheiro Excel principal. O Power BI estava a ler a partir desse ficheiro. A cadeia introduzia pelo menos uma semana de desfasamento entre a realidade e o relatório.
O redesenho tinha três partes: um processo de submissão de estado normalizado com um corte fixo às sextas-feiras que o Power BI lia diretamente, uma separação clara entre um one-pager executivo (RAG do portfólio, cinco principais riscos, variação orçamental por programa) e uma visão operacional ao nível do programa, e a substituição de um gráfico de barras empilhadas genérico por um visual de cronologia de marcos adequado que mostrava o desvio do calendário num relance.
A reunião de direção passou de três horas para setenta minutos. Mais importante ainda, a pergunta de abertura deixou de ser "podemos confiar nisto?" e passou a ser "o que fazemos em relação ao Programa B?" Essa mudança - da validação de dados para a tomada de decisões - é o verdadeiro objetivo. Tudo o resto são infra-estruturas.
De acordo com Investigação do PMI sobre a eficácia do PMOEm termos gerais, as organizações com processos maduros de elaboração de relatórios de carteira concluem significativamente mais projectos dentro do prazo e do orçamento. Não são os relatórios em si que causam isso - mas os maus relatórios escondem ativamente os sinais que permitiriam uma intervenção precoce.
Por onde começar
Se o seu relatório de portfólio estiver a gerar mais debates em reuniões do que decisões de direção, o diagnóstico mais rápido é perguntar: o que é que o comité executivo decide realmente com base neste relatório? Se a resposta honesta for "não muito", o relatório não está a fazer o seu trabalho - independentemente da solidez técnica da construção subjacente do Power BI.
Comece por aí. Defina as três decisões que o comité de direção tem de tomar mensalmente. Construa de trás para a frente. Depois, preocupe-se com o aspeto visual.
Se já tiver ultrapassado isso e o estrangulamento for a própria camada do Power BI, o Biblioteca visual do LeapLytics vale a pena dar uma vista de olhos - concebido especificamente para contextos de elaboração de relatórios de gestão de projectos, certificado pela Microsoft e disponível para avaliação direta. Iniciar um teste gratuito aqui e testá-los em relação aos dados reais da sua carteira.
