A melhor alternativa ao Asana para um project management office: sete tarefas que tem de cumprir

Quando um PMO ultrapassa o Asana

Vale a pena ser preciso sobre aquilo em que o Asana é bom, porque um PMO que diagnostica mal o problema compra o substituto errado. O Asana dá às equipas um lugar partilhado para tarefas, responsáveis, datas, comentários e ficheiros. Aprende-se depressa, não exige um administrador e as pessoas usam-no voluntariamente, o que é uma fasquia mais alta do que a que a maioria do software empresarial ultrapassa. Para coordenar o trabalho dentro de uma equipa são as propriedades certas, e uma comparação capacidade a capacidade no comparativo entre o FlexiProject e o Asana mostra onde as duas ferramentas realmente divergem.

O ponto de viragem chega quando muda a própria produção do PMO. Coordenar o trabalho responde à pergunta de quem faz o quê e para quando. Governar um portefólio, que na maioria das organizações é o papel central do PMO, responde a outras perguntas: a organização está a financiar as iniciativas certas, cada uma ainda tem a sua justificação, o dinheiro e as pessoas afetos a elas estão disponíveis, e o que dizer à direção. Estas perguntas não são versões mais difíceis da primeira. Precisam de outros dados por baixo, e uma ferramenta construída em torno das tarefas não os contém.

A consequência é que o PMO se torna a camada de compensação. Cada capacidade que a ferramenta não tem é coberta por uma pessoa: alguém monta a vista de portefólio, alguém repara no projeto que saltou a revisão, alguém reconcilia o orçamento com o sistema de contabilidade. Nada disto aparece como custo de licença, pelo que muitas vezes decorre durante anos antes de alguém o contar, e é por isso que um rastreador de tarefas não basta a um PMO.

A semana antes da revisão de portefólio

A forma reconhecível do problema é a semana que precede a reunião de direção. Alguém abre trinta ou quarenta espaços de projeto um a um, copia um estado de um e uma percentagem de outro e cola-os numa apresentação já desatualizada antes mesmo de a reunião começar. Os próprios estados dependem de os gestores de projeto se lembrarem de os atualizar, pelo que a vista de direção nunca está mais atualizada do que a última pessoa que lhe tocou.

Uma governação que alguém tem de vigiar à mão

A segunda metade da tarefa é a aplicação. Um PMO não se limita a observar os projetos, mantém-os dentro de um processo: um business case antes do financiamento, uma revisão antes da fase seguinte, uma alteração aprovada antes de o âmbito crescer. Os campos personalizados e as regras de automatização podem registar que um ponto de controlo ocorreu, mas nada avalia se já deveria ter ocorrido, pelo que alguém tem de reparar no projeto que passou a execução sem uma carta aprovada. Em cinco projetos é uma conversa; em quarenta, distribuídos por vários departamentos, é um papel administrativo a tempo inteiro, e é a primeira coisa a ser abandonada quando o PMO está sobrecarregado. À parte detalhamos o que é um verdadeiro controlo do orçamento do projeto.

O que uma alternativa ao Asana tem de fazer por um PMO

Uma vez clara a diagnose, a lista de requisitos encurta. Estes sete critérios são os que separam um sistema de portefólio de uma ferramenta de tarefas com um painel por cima, e cada um corresponde a algo que um PMO produz em vez de uma categoria de funcionalidades.

Em conjunto descrevem o que um software para PMO tem de cobrir antes de poder carregar a governação de portefólio. O resto do artigo pega neles um a um, na ordem em que um PMO os encontra ao longo de um ano. Também vemos o que procurar quando se consideram aplicações como o Asana.

Admissão: decidir que projetos entram

A primeira coisa de que um PMO é responsável é a decisão sobre o que entra no portefólio. Na maioria das organizações esta decisão toma-se com uma mistura de estratégia, precedente e quem argumentou com mais insistência, e defende-se depois em vez de antes. Uma ferramenta de tarefas não tem nada a oferecer aqui, porque a admissão acontece antes de haver um projeto para acompanhar.

O FlexiProject resolve isto com um módulo de pontuação de projetos construído sobre o modelo próprio da organização. Define os critérios que contam, seja o alinhamento com a estratégia, o retorno esperado, a exposição ao risco ou a disponibilidade de recursos, atribui pesos e fixa a precisão exigida das respostas. As ideias são então pontuadas na mesma base, e o PMO tem uma classificação que pode levar a um comité de acompanhamento sem se apoiar na persuasão.

Dois detalhes fazem a diferença entre um modelo de pontuação que é usado e um que é abandonado. O primeiro é que cada pergunta de pontuação pode ser dirigida ao seu próprio grupo de avaliadores. As perguntas sobre a complexidade técnica vão para os arquitetos, as sobre a rentabilidade para o controlo de gestão, as sobre a exposição jurídica para o departamento jurídico, e a pontuação final agrega vários pareceres informados em vez de uma pessoa a adivinhar fora do seu domínio. O segundo é que a pontuação não se limita ao arranque. Um projeto pode ser reavaliado durante a execução à medida que chega nova informação, o que dá ao PMO um mecanismo que muitas vezes lhe falta: um modo estruturado de parar uma iniciativa que já não merece o seu orçamento, antes de consumir mais dois trimestres.

Relatórios de estado sem montar slides

Relatórios desenhados uma vez, atualizados a partir daí

O FlexiProject divide isto em dois mecanismos. As revisões de projeto automatizadas recolhem o estado junto dos gestores de projeto a uma cadência definida, pelo que a entrada chega sem uma ronda de insistências. O gerador de relatórios compõe depois a saída a partir de dados em direto: qualquer relatório pode ser desenhado num construtor e cobre projetos, tarefas, marcos, rubricas de orçamento, riscos, entregáveis ou alterações ao plano, filtrados segundo os critérios que a pergunta exige.

O efeito prático vê-se nos pedidos pontuais. Quando um membro da direção pede cada projeto acima de um certo orçamento cujo marco derrapou neste trimestre, a resposta atual é muitas vezes uma tarde de exportações de vários sítios. Desenhada uma vez no construtor de relatórios, essa pergunta torna-se um relatório permanente disponível de imediato com dados atualizados, e da próxima vez que a fazem não há trabalho. Um PMO que faz isto há um ano dispõe de uma biblioteca que cobre a maior parte do que a direção pede regularmente, que é a forma prática de reportar o estado dos projetos de forma mais eficaz sem acrescentar uma reunião.

Quando o PMO deixa de ser o estrangulamento dos relatórios

A segunda mudança é estrutural. Na maioria das organizações, cada departamento pede ao PMO o seu próprio corte dos dados: a área financeira quer os custos por categoria, fornecedor e período, o jurídico quer os riscos jurídicos reunidos de todo o portefólio, uma divisão de produção quer apenas os seus próprios projetos. Cada pedido é um trabalho à parte, e o PMO torna-se uma fila.

Como os relatórios são desenhados em vez de compilados, cada departamento pode ter o seu próprio conjunto. O PMO constrói-os uma vez e mantêm-se disponíveis com dados atualizados, exportáveis para Excel para quem quiser continuar a trabalhar os números. A área financeira lê os seus próprios relatórios, o jurídico a sua própria lista de riscos, e o PMO deixa de arbitrar o acesso a informação que não lhe pertence.

Revisões de portefólio que vão além dos três minutos por projeto

A revisão de portefólio é onde a governação ou acontece ou se encena. Uma reunião de duas horas que cobre quarenta projetos, quinze dos quais com problemas reais, dá a cada um três minutos. Não é uma revisão. É uma sucessão de slides com quórum, e toda a gente na sala o sabe.

O mecanismo que corrige isto é a síntese antes do detalhe. O software de portefólio de projetos apresenta o portefólio num só ecrã: estado dos marcos, saúde do projeto, desvio de orçamento, progresso face ao plano. A direção ou o comité de acompanhamento identifica em segundos que projetos precisam de uma discussão a sério, e esses projetos recebem um formato mais aprofundado com tempo dedicado, enquanto os que estão em linha com o plano passam num minuto. A reunião deixa de ser uma sequência de relatórios e torna-se uma sequência de decisões, e como o módulo de revisões de projetos agenda a cadência e retira o material dos próprios projetos, a preparação desaparece com ela.

Pontos de controlo de fase e alterações ao plano que deixam registo

Um plano aprovado em janeiro e um plano em vigor em junho raramente são o mesmo plano, e a diferença entre um portefólio governado e um que não é está em saber se alguém consegue dizer como mudou. Numa ferramenta de tarefas, o plano torna-se simplesmente o que é no instante, e o raciocínio vive nos emails.

O FlexiProject trata uma alteração ao plano como um objeto formal. Qualquer alteração significativa de datas, orçamento ou âmbito pode ser levantada como pedido de alteração com uma justificação de negócio, e o pedido mostra o plano atual e o proposto lado a lado, incluindo o diagrama de Gantt no módulo de cronograma do projeto, pelo que o decisor vê a dimensão daquilo que aprova em vez de ler uma descrição. O pedido passa depois por um circuito de aprovação e, uma vez aprovado, torna-se a nova versão do plano. Cada pedido é arquivado, o que significa que o PMO pode reconstruir anos depois como um projeto evoluiu e porquê, que é exatamente aquilo de que uma auditoria ou um exercício de lições aprendidas precisa e quase nunca tem. Em separado explicamos como abordar o planeamento de projetos que o sistema mantém sozinho.

A capacidade dos recursos que o PMO pode defender

O FlexiProject aborda isto como software de gestão de recursos: modela a disponibilidade por pessoa e por dia, férias e ausências incluídas, e assinala quando a carga planeada excede o que está disponível num dado período. É isto que recupera a situação conhecida em que um especialista aparece ao mesmo tempo nos planos de dez projetos, cada plano razoável isoladamente e a soma impossível. A carga é visível diretamente a partir do diagrama de Gantt, pelo que deslocar uma tarefa no tempo mostra logo o efeito na capacidade, o que torna o planeamento uma simulação que o gestor de projeto corre antes de aprovar o plano.

Acima do projeto individual, o PMO obtém uma vista de todos os recursos de projeto para os meses seguintes, repartida por estrutura organizacional. É esta vista que permite ao PMO dar uma resposta defensável a duas perguntas que lhe fazem regularmente e a que costuma responder por instinto: comprometer-se ou não com a oportunidade que está na mesa, e quando o recrutamento tem de começar para os compromissos já assumidos. Para um PMO numa organização cuja receita depende dos projetos, esta vista é um instrumento comercial, não uma comodidade de planeamento.

Dinheiro e risco acima do projeto individual

Duas coisas são visíveis ao nível do portefólio e invisíveis projeto a projeto. Ambas são normalmente responsabilidade do PMO e nenhuma cabe numa ferramenta de tarefas.

Desvio de orçamento com previsão até à conclusão

Um campo com um número de orçamento não é gestão de orçamento. Gerir o orçamento de um projeto significa saber, por linha, o que foi planeado, o que foi gasto e o que ainda deverá ser gasto antes do fecho do projeto. O módulo de orçamento do projeto mostra estes três valores com o desvio resultante, do lado dos custos e do lado das receitas, pelo que para os projetos que geram receita o PMO vê o resultado financeiro previsto e não apenas as despesas.

Um registo de riscos que o portefólio consegue ler

Um risco numa ferramenta de tarefas é uma tarefa com uma etiqueta. Num sistema de portefólio é um registo com avaliações, responsáveis, planos de resposta e histórico, e tem um nível acima do projeto. O registo de riscos do FlexiProject tem um nível de portefólio: cada portefólio tem o seu próprio separador de riscos que reúne os riscos de todos os seus projetos num só lugar.

O que isto faz emergir é a duplicação. Três gestores de projeto que gerem de forma independente o mesmo risco de fornecedor dedicam-lhe o triplo do esforço e chegam a três conclusões diferentes, e ninguém o vê porque cada registo está completo nos seus próprios termos. Ao nível do portefólio, esse risco recebe um responsável e uma resposta. Os relatórios de riscos funcionam também no sentido inverso: uma equipa que arranca com um novo projeto pode extrair os riscos registados em projetos semelhantes e partir da experiência da organização em vez de um registo vazio e uma hora de imaginação. Mostramos igualmente como funciona a gestão de riscos do projeto na prática.

Carregar o seu padrão de PMO, não o do fornecedor

Uma carta e uma matriz de riscos que se ajustam ao que já usa

O módulo de carta de projeto é montado a partir de componentes sem programação, pelo que o documento reflete a disposição que a organização já usa. Mais do que um padrão de carta pode existir ao mesmo tempo: projetos de desenvolvimento com campos relevantes para a I&D, projetos de marketing com diferenciadores de mercado e canais, projetos de investimento com campos de tecnologia e retorno, enquanto um conjunto de campos empresariais permanece comum a todos. Os departamentos não são forçados a um documento de compromisso que não serve a nenhum, o que costuma matar a padronização.

A matriz de riscos funciona da mesma forma. As suas dimensões configuram-se durante a implementação, pelo que uma organização que trabalha há anos com uma avaliação três por três não é obrigada a passar a cinco por cinco só porque o software o pressupõe. As cartas são versionadas e aprovadas eletronicamente, e uma parte de cada uma preenche-se sozinha a partir do cronograma e do registo de riscos, pelo que o documento se mantém coerente com os dados subjacentes em vez de envelhecer a partir do dia da assinatura.

Circuitos de aprovação por área de trabalho

As regras de aprovação raramente são uniformes numa organização, e quase nunca num grupo de empresas. O FlexiProject permite circuitos de aprovação dedicados por área de trabalho: um circuito de aprovação de orçamento distinto numa divisão de produção, um circuito partilhado onde a partilha faz sentido, um circuito curto para os projetos operacionais e um mais longo para os estratégicos. O PMO codifica as regras que existem em vez de as negociar em baixa para um único circuito que toda a gente tolera.

Há um benefício secundário que os responsáveis de PMO notam ao fim de um ano. Quando a carta, os modelos, os circuitos de aprovação e os formatos de revisão vivem todos no sistema, a metodologia deixa de viver na cabeça de colegas experientes. Um novo membro do PMO aprende o padrão da organização ao aprender a ferramenta, e a integração que antes levava meses reduz-se consideravelmente.

Implantação: níveis de licença, línguas e alojamento

O primeiro é o modelo de licenciamento. O sistema de gestão de projetos FlexiProject cobra o acesso por papel em vez de por cabeça. A maioria dos sistemas cobra uma tarifa comparável a toda a gente, o que significa que a organização paga um lugar completo por pessoas que abrem a ferramenta para atualizar as suas próprias tarefas e consultar um estado. Oferece três níveis ajustados ao papel real: uma licença completa para gestores de projeto, membros do PMO, patrocinadores e decisores, uma licença standard para os participantes ativos que reportam progresso e colaboram nas tarefas, e uma licença gratuita para quem só precisa de visibilidade sobre o próprio trabalho. O PMO decide a mistura, o que torna a cobertura da organização mais ampla proporcionada em vez de uma negociação de orçamento.

O segundo é a língua. A interface está disponível em 28 línguas e a documentação de utilizador em 11, o que importa para um PMO num grupo com filiais em vários países. Um padrão e um sistema, com cada um a trabalhar na sua própria língua, é muitas vezes a diferença entre uma adoção real e um uso cortês mas nulo nas instalações mais pequenas.

O terceiro é o alojamento. O FlexiProject está disponível on-premises a par da nuvem. Para as organizações em setores regulados, ou com uma política interna sobre onde residem os dados, não é uma preferência mas a condição para sequer ser avaliado.

Quando não é a resposta certa para o seu PMO

Um PMO que acompanha três ou quatro projetos sem orçamento formal e sem compromissos externos de datas ainda não precisa de governação de portefólio, e introduzi-la acrescentará processo sem acrescentar controlo. A recomendação honesta aí é manter a ferramenta de tarefas e voltar à pergunta quando o portefólio crescer.

E se a tarefa central do PMO é modelar orçamentos de investimento e prever recursos sobre milhares de pessoas num contexto de investimento de capital fortemente regulado, as plataformas pesadas construídas exatamente para isso justificarão o seu custo de implementação. O argumento a favor do FlexiProject é mais forte onde o PMO precisa de governação, visibilidade de portefólio e relatórios automatizados sem um projeto de configuração de vários trimestres.

Como verificá-lo em duas semanas

Reconstrua três projetos reais, não projetos de demonstração. Pegue num projeto grande com dependências, num pequeno projeto operacional e num que esteja em dificuldades neste momento, com os seus cronogramas, pessoas e orçamentos reais. O atrito que encontra é o atrito que encontrará todas as semanas, e serve ainda de formação, porque quem aprende o sistema nos seus próprios projetos retém mais do que quem faz um exercício com dados inventados.

Depois, corra quatro testes que apontam à própria produção do PMO. Produza o relatório que costuma montar à mão e cronometre-o. Faça uma revisão de portefólio usando apenas o que está no ecrã, sem uma apresentação preparada. Empurre uma alteração ao plano através de um circuito de aprovação e verifique se o registo mostra depois o que mudou e quem o aprovou. Afete uma pessoa já comprometida noutro lado e veja se o sistema o avisa antes da aprovação do plano. Uma ferramenta que trata destes quatro tratará do resto; uma ferramenta que falha neles não será salva por campos personalizados.

Perguntas frequentes

O Asana é uma ferramenta de gestão de portefólio de projetos?

Não no sentido de que um PMO precisa. O Asana é gestão do trabalho construída em torno de tarefas, projetos e colaboração, com vistas de portefólio e objetivos nos seus níveis superiores. Essas vistas resumem a atividade das tarefas em vez de governar um portefólio face à estratégia, ao orçamento e aos pontos de controlo, e dependem de os gestores de projeto manterem os estados atualizados à mão. Um sistema de portefólio dedicado lê o estado do portefólio a partir dos dados subjacentes.

De que precisa um PMO que uma ferramenta de tarefas não fornece?

Sete coisas na prática: uma pontuação de admissão objetiva, relatórios sobre dados em direto, uma síntese de portefólio num ecrã, pontos de controlo e gestão de alterações aplicáveis, capacidade à escala de toda a organização, consolidação financeira e de riscos acima do projeto, e um padrão configurável. Uma ferramenta de tarefas pode aproximar-se de algumas com campos personalizados, mas a aproximação é mantida pelo PMO, não pelo sistema.

Os gestores de projeto podem continuar a trabalhar como agora?

Em grande parte sim, e é o principal fator que determina o sucesso de uma implantação. O cronograma está disponível como lista de tarefas, diagrama de Gantt e quadro Kanban sobre os mesmos dados, pelo que um gestor de projeto que trabalha num quadro pode continuar a trabalhar num quadro enquanto a camada de portefólio se mantém coerente. O que muda é que o progresso é reportado nas tarefas e consolidado automaticamente, em vez de digitado como percentagem ao nível da fase.

Toda a organização precisa de uma licença paga?

Não. Estão disponíveis três níveis de licença, e o nível gratuito cobre as pessoas que precisam de visibilidade sobre o próprio trabalho e de informação básica do projeto. Na maioria das organizações esta é uma grande fatia dos utilizadores, o que mantém o custo de cobrir a equipa alargada proporcional ao que essas pessoas retiram.

Podemos manter a nossa carta e a nossa matriz de riscos atuais?

Sim, e vale a pena insistir nisso. A carta é construída a partir de componentes, com vários padrões de carta que podem coexistir para diferentes tipos de projeto, e as dimensões da matriz de riscos configuram-se durante a implementação. Um PMO não tem de abandonar uma escala de avaliação que a organização compreende para adotar o sistema.

A procura da melhor alternativa ao Asana para um project management office começa quase sempre como uma comparação de ferramentas e resolve-se numa pergunta sobre a própria carga de trabalho do PMO. Se o gabinete passa o mês a juntar informação que já existe, a vigiar pontos de controlo à mão e a defender decisões de recursos por instinto, a capacidade de que precisa não é um quadro de tarefas melhor. São uma pontuação de admissão que pode levar a um comité, relatórios desenhados uma vez e atualizados a partir daí, um portefólio que lê em segundos, alterações que deixam registo, uma capacidade que pode defender, e tudo isto a carregar o padrão que a organização já afinou em vez da versão de um fornecedor. A forma fiável de saber se é a sua situação é pegar em duas semanas, três projetos reais e o relatório que receia montar, e ver quanto o sistema produz sem si.