De cima para baixo ou de baixo para cima
Este artigo faz parte da nossa coleção "From the Trenches". Ele discute o gerenciamento de projetos, o gerenciamento de portfólio e o gerenciamento de tarefas e compara as práticas de gerenciamento de cima para baixo e de baixo para cima relacionadas a elas.
Para baixar a versão do Word deste artigo, confira De cima para baixo ou de baixo para cima: white paper (Project Server 2010) .
Para ver mais artigos, consulte white papers "From the Trenches".
De cima para baixo ou de baixo para cima?
"Precisamos de gerenciamento de projetos... Hum, eu quis dizer gerenciamento de portfólio... Hum, eu realmente quero dizer gerenciamento de tarefas... Oh caramba, precisamos de todos eles", é um grito de batalha que ouço com frequência. Não é falta de definições desses três conceitos que causam confusão, é a semelhança deles.
Aqueles de nós que trabalharam em TI por muitos anos tendem a ver as coisas de uma perspectiva técnica e às vezes não nos serve bem. Se examinarmos os dados de Gerenciamento de Portfólio, Gerenciamento de Projetos e Gerenciamento de Tarefas, ele poderá ser muito semelhante. Tenho um campo de ID, um campo de descrição e uma data de início e término em todos os três. Vincular todos esses três deve ser natural então.
Talvez não.
Vamos levar esses três conceitos um de cada vez. É fácil ver suas semelhanças, mas há diferenças fundamentais nas três perspectivas.
Gerenciamento de Portfólio – uma abordagem de cima para baixo
Pessoas pode significar muitas coisas diferentes por "gerenciamento de portfólio", mas o mais comum é provavelmente a seleção e a priorização do projeto. Os princípios acabam afetando todos na organização, mas o processo é de grande interesse para executivos seniores. O gerenciamento começa com determinadas restrições, como um orçamento total disponível e a necessidade de responder à pergunta: "O que podemos e devemos realizar com essa quantidade de dinheiro?" Se o processo de gerenciamento de portfólio for suficientemente maduro, essa análise poderá incluir não apenas novas ideias, mas também projetos existentes.
Para criar um processo de seleção e priorização de portfólio, o gerenciamento deve confrontar quais critérios de negócios impulsionam a empresa e concordar com antecedência sobre as métricas que serão consideradas ao analisar projetos novos e existentes. O retorno do investimento deve ser uma métrica fundamental? Talvez devamos considerar efeitos sobre a satisfação do cliente ou a retenção ou alinhamento da equipe com objetivos estratégicos. Quaisquer que sejam as principais métricas, o gerenciamento precisa pesar cada iniciativa do projeto com vistas a como esse projeto pode avançar esses objetivos e como cada projeto se compara com iniciativas alternativas nas quais o dinheiro pode ser gasto.
Esse é um processo altamente analítico, mesmo que seja feito na cabeça. É certamente altamente analítico quando você está usando o software de gerenciamento de portfólio de projetos. Mesmo quando a análise do software chega em um relatório ou uma exibição, há praticamente sempre alguma supervisão no nível de gerenciamento em que uma decisão final sobre prioridades é tomada. Quando isso for concluído, os resultados finais devem ser transmitidos para aqueles que farão o gerenciamento de projeto de cada um dos projetos. Os efeitos dessas decisões serão financiar alguns projetos e não financiar outros, disponibilizar recursos com maior prioridade para alguns projetos e não para outros, além de avançar na agenda de alguns projetos e atrasar outros.
Gerenciamento de Projetos – de cima para baixo e de baixo para cima
Depois que um projeto é aprovado, ele passa para um reino completamente diferente. Agora, a exibição mais clássica do agendamento de projetos entra em foco. Agora temos que realmente construir a coisa que descrevemos em nossa justificativa comercial antes de ser aprovada.
Um gerente de projeto começa a pensar em termos de escopo de projeto e entregas. O gerente de projeto conhece o produto final que deve ser criado, seja um software ou um edifício pronto para ocupação. Eles podem pensar nas fases principais desse projeto e criar uma estrutura de divisão de trabalho.
Um caminho crítico das etapas lógicas necessárias para concluir o projeto é projetado. O gerente do projeto também sabe que ele ou ela será responsabilizado pela agenda produzida, portanto, ele ou ela consulta uma série de especialistas em assuntos no projeto. O gerenciador de projetos cria uma visão de baixo para cima do projeto procurando tarefa por tarefa e resumindo essas tarefas até fases de projeto e, eventualmente, para o projeto em si. Neste momento, o gerente de projeto também pode começar a alocar recursos por habilidade, por departamento ou até mesmo pelo nome. Esses recursos podem ter custos associados a eles. O resultado de calcular a duração das tarefas, os recursos necessários e suas taxas nos dá uma estimativa inferior do projeto.
Até aqui, tudo bem.
Mas quando olhamos para a abordagem de cima para baixo do processo de seleção do portfólio de projetos, houve um custo, também. Na verdade, o custo estimado do projeto fazia parte da justificativa comercial que a administração considerou quando aprovou o projeto. Se estamos apenas obtendo a estimativa de baixo para cima do projeto de experiência combinada dos especialistas em assunto agora, o que eles usaram na seleção do projeto no pacote executivo?
É uma boa pergunta. Em algumas organizações, o projeto receberá uma estimativa aproximada do departamento de projetos para criar uma justificativa comercial para o projeto. Em outras organizações, uma estimativa completa de baixo para cima é criada antes de considerar o projeto no processo de portfólio. O problema com ambas as abordagens é que elas se esforçam. Uma estimativa completa pode ter muito esforço e, no entanto, o projeto ainda não recebeu aprovação para financiar qualquer esforço. Assim, em muitas organizações, alguém na gestão simplesmente faz um palpite sobre quais serão os custos deste projeto.
Portanto, o processo parece todo integrado, mas pode haver um pouco de um catch-22 aqui. Que vem primeiro, o trabalho gasto em fazer a estimativa ou a seleção do projeto para poder gastar tempo no projeto?
Além disso, o que acontecerá se a estimativa de baixo para cima não corresponder à estimativa do processo de seleção de portfólio? Se a estimativa for menor, provavelmente não haverá problema, mas se o trabalho não puder ser concluído no tempo ou orçamento estimado pelas pessoas da seleção de portfólio, haverá um conflito.
Você pode pensar que a coisa natural a fazer seria reunir novamente a alta administração e apenas discutir o problema, mas há muitas situações em que isso não é tão fácil quanto parece.
Em primeiro lugar, o comitê de seleção de portfólio raramente é a equipe de gerenciamento de projetos. Os membros seniores da equipe de gerenciamento de projetos são quase sempre incluídos no comitê de seleção de portfólio, mas o grupo em si geralmente é um executivo muito sênior que acha desafiador organizar o tempo para todos estarem juntos. Em segundo lugar, o comitê de seleção pode se reunir irregularmente, então reuni-los novamente para discutir todas as ramificações de um custo incompatível para um projeto versus a estimativa pode ser um grande desafio. Finalmente, há algumas culturas corporativas em que não será um movimento de avanço na carreira ter que entregar a notícia ao executivo sênior de que seu palpite está completamente errado sobre qual é a agenda e o orçamento apropriados para este projeto.
Gerenciamento de tarefas – uma abordagem de baixo para cima
Quando pensamos em gerenciamento de tarefas, tendemos a pensar muito operacionalmente, e isso na maioria das vezes nos leva à nossa agenda diária e a um produto como o Outlook.
Agora estamos trabalhando em um nível individual ou de um pequeno membro da equipe. Não vemos as tarefas no contexto. Vemos essas coisas com as quais nos comprometemos ou talvez aquelas coisas com as quais pedimos a um membro da equipe para se comprometer. Essa não é uma exibição analítica. Há tarefas a serem cumpridas e o indivíduo prometeu fazê-las.
Em sua essência, o gerenciamento de tarefas é muito simples. Você faz a tarefa e quando terminar, você diz à pessoa que lhe deu a tarefa para fazê-la está concluída. Toda a funcionalidade para isso já está no Outlook.
O mal de dados semelhantes
Há um ditado: "Se parece com um pato e charlatães como um pato, deve ser um pato." Isso é verdade para os patos, mas nem sempre é verdade para dados baseados em tarefas.
Vamos considerar esses três níveis de dados orientados ao projeto:
No nível do portfólio, temos um projeto e talvez fases abaixo desse projeto. As informações de fase podem ter um número de código, uma descrição, uma duração, uma data de início e uma data de término.
No nível do projeto, temos um projeto e tarefas abaixo do projeto. As informações da tarefa podem ter um número de código, uma descrição, uma duração, uma data de início e uma data de término.
Nesse nível de gerenciamento de tarefas, temos uma tarefa e as informações da tarefa podem ter um número de código, uma descrição, uma duração, uma data de início e uma data de término.
Eles parecem iguais, mas, na verdade, a perspectiva dos dados faz com que cada um desses registros bastante comuns sirva a um propósito muito diferente.
Muitas vezes me perguntam: "Posso mover dados da exibição do portfólio para a exibição do projeto para o Outlook e voltar."
A resposta curta para essa pergunta é "Sim".
Mas em nossa empresa temos um mantra que dizemos a nós mesmos quando estamos dando conselhos técnicos: "Não me diga como fazer isso, diga-me por que você deve fazê-lo."
Para fazer o ponto, imagine este exemplo. Fazemos um ambiente totalmente integrado. Na parte superior da escala, temos uma lista de projetos organizados por portfólio. Não só selecionamos esses projetos, mas nos integramos ainda mais, seguindo-os depois que eles foram ativados em projetos ao vivo do sistema EPM. Para fazer isso, usamos a funcionalidade já disponível para mover as definições de projeto e fase do lado do Portfólio do nosso sistema integrado para o lado do projeto do sistema. Os dados parecem idênticos.
Em nosso sistema de gerenciamento de projetos corporativos, agora fazemos uma definição mais detalhada, usando as fases originais da definição de portfólio que foi enviada por push de cima para baixo. Fazer isso permite que esse resumo seja atualizado no sistema de portfólio quando atualizarmos nossos projetos. Fazemos muitas tarefas e atribuimos muitos recursos. Agora fazemos uma análise de nivelamento de recursos para determinar nossa capacidade em muitos projetos.
Usamos nossas atribuições de recurso para enviar dados de tarefa e atribuição a cada usuário como uma tarefa ou evento de calendário do Outlook. Os usuários não precisam mais ir para um "sistema de gerenciamento de projetos". Agora eles podem ver seus dados em sua agenda diária. Os dados são semelhantes aos da lista de projetos e são vinculados ainda mais upstream à exibição do portfólio.
O progresso dessas tarefas e a disponibilidade do Outlook são movidos de volta do indivíduo para o sistema de gerenciamento de projetos, juntamente com estimativas sobre quando esse trabalho será concluído. Os dados se parecem com os outros dois sistemas, portanto, mover os dados é relativamente fácil.
A criação desse sistema é tecnicamente muito simples usando as ferramentas disponíveis para nós hoje, juntamente com um pouco de configuração e desenvolvimento. E isso demonstraria lindamente.
Nos pedem exatamente esse tipo de estrutura regularmente. Mas, mesmo que possamos fazer isso, deveríamos?
Imagine que no nível da tarefa, um indivíduo tira a manhã de folga para uma visita odontológica de emergência e atualiza seu Outlook que ela não estará disponível esta manhã. Isso é uma má notícia para ele, mas os efeitos da onda para o projeto podem ser enormes. Agora, o sistema de projetos calcula que a tarefa que estava agendada para ser concluída esta manhã não será concluída hoje; ele será concluído somente no meio do dia de amanhã. Ele olha obedientemente para o caminho crítico e todas as tarefas downstream deste e empurra-as para a frente em quatro horas. Talvez centenas de tarefas tenham sido afetadas. O resultado pode estar adiando a data de término do projeto meio dia depois. Outros projetos também são afetados, pois outras pessoas que trabalham neste projeto agora devem ter suas tarefas reorganizadas e a própria exibição de portfólio desliza para a frente alguns pixels.
Se imaginarmos isso em tempo real, o problema será ampliado. Centenas ou milhares de pessoas estão fazendo alterações durante todo o dia, e a exibição EPM, a exibição de nivelamento de recursos e a exibição de portfólio animam para frente e para trás com os efeitos.
Na realidade, isso não acontece. Em primeiro lugar, a infeliz paciente dentária estará de volta ao seu posto ao meio-dia e pode trabalhar algumas horas depois esta noite para garantir que este caminho crítico esteja preso e tudo estará de volta aos trilhos pela manhã.
Além disso, mesmo que os dados tenham a mesma aparência, eles nunca são integrados dessa forma devido exatamente a esse efeito.
Contexto de Dados – a perspectiva importa
Quando olhamos para os dados, o contexto dos dados é crítico. Os dados que podem parecer iguais de um esquema de registro em registro são usados para fins muito diferentes com base na perspectiva do aplicativo.
Em uma visão de portfólio de cima para baixo, estamos tomando decisões estratégicas de onde colocar nossos recursos para maximizar nosso retorno sobre o investimento. Podemos fazer escolhas que um gerente de projeto não faria. Na minha própria organização, às vezes escolhemos projetos que estão completamente fora do nosso conjunto de habilidades existentes, sabendo que seríamos terrivelmente ineficazes em realizá-los, mas fazê-lo porque queríamos melhorar essas próprias habilidades. O retorno do investimento não foi uma instalação eficaz, foram instaladores treinados. Essa é uma exibição analítica.
Em uma visão de projeto tático, estamos tomando decisões operacionais sobre onde obter a melhor taxa de transferência de nosso pessoal e para concluir nossos projetos o mais rápido e eficientemente possível. O olho de um gerente de projeto é sempre para o futuro. O que aconteceu no passado é apenas de interesse para o gerente de projeto na medida em que melhora sua visão do futuro. Essa também é uma exibição altamente analítica.
Em uma exibição de gerenciamento de tarefas como uma agenda, não estamos analíticos. Uma agenda é um sistema de compromisso. Prometemos a nós mesmos ou a outros que faremos uma coisa específica em um determinado momento. Isso pode se encaixar na exibição analítica. E talvez não.
Misturar essas perspectivas e contextos sem entender o impacto pode causar caos.
De cima para baixo ou de baixo para cima?
Não há, como de costume, nenhuma resposta certa. Alguns aspectos do sistema de gerenciamento de projetos realmente precisam vir de baixo para cima. Afinal, no final, são os indivíduos que criarão qualquer que seja o seu projeto. Mas algumas decisões são, e devem ser tomadas desde o início e são, como necessidade, de cima para baixo.
Quando você mantém as distinções de para que serve cada nível do paradigma de gerenciamento de projetos, fica mais claro ver se alguns desses sistemas devem realmente ser integrados ou não. Se o processo e o pensamento de um nível não tiverem benefício direto sendo totalmente integrados de outro nível, a integração não será o melhor jogo. É importante percorrer como essa integração funcionaria em um contexto real e se a frequência e os detalhes de um nível fornecem qualquer valor para o outro.
Se, por exemplo, um comitê gestor se reunir apenas uma vez por trimestre para tomar decisões importantes sobre quais projetos avançar e quais não, qual é o benefício de atualizar sua visão todos os dias, todas as semanas ou até mesmo todos os meses?
O algoritmo de nivelamento de recursos de gerenciamento de projetos corporativos realmente precisa ver a consulta odontológica de um indivíduo ou é suficiente para saber a disponibilidade aproximada desse indivíduo?
E, no entanto, se pudéssemos enviar uma atribuição para a agenda ou tela de folha de tempo de um indivíduo diretamente, isso os salvaria alguns minutos por dia tendo que entrar em um sistema e interface diferente para ver os mesmos dados?
Então, de cima para baixo está certo em algumas circunstâncias e de baixo para cima está certo em outros. Você tem que olhar para sua própria situação para ver onde a integração dessas ferramentas e conceitos pode pagar os dividendos certos antes de amarra-los juntos.
Sobre o autor
Chris Vandersluis é presidente e fundador da Montreal, hms software com sede no Canadá, um parceiro certificado pela Microsoft. Ele é formado em economia pela Universidade McGill e tem mais de 30 anos de experiência na automação de sistemas de controle de projetos. Ele é membro de longa data do PMI (Project Management Institute) e ajudou a fundar os capítulos montreal, Toronto e Quebec do Grupo de Usuários do Projeto Microsoft (MPUG). As publicações para as quais Chris escreveu incluem Fortune, Heavy Construction News, Computing Canada magazine, e PMNetwork do PMI, e ele é um colunista regular do Project Times. Ele ensina Gerenciamento Avançado de Projetos na Universidade McGill e frequentemente fala em funções de associação de gerenciamento de projetos em América do Norte e em todo o mundo. O HMS Software é o editor do sistema de timekeeping orientado ao projeto TimeControl e é um Parceiro de Solução de Projeto da Microsoft desde 1995.
Chris Vandersluis pode ser contatado por email em: chris.vandersluis@hms.ca
Se você quiser ler mais artigos relacionados ao EPM por Chris Vandersluis, consulte o site de Diretrizes do EPM do HMS (https://www.epmguidance.com/?page_id=39).