White paper De cima para baixo ou de baixo para cima

Este white paper faz parte da nossa coluna “From the trenches” (Nas trincheiras). Discute o gerenciamento de projetos, o gerenciamento de portfólios, o gerenciamento de tarefas e compara as práticas de gerenciamento de cima para baixo e de baixo para cima relacionada a eles.

Para baixar a versão do Word deste white paper, consulte White paper De cima para baixo ou de baixo para cima (Project Server 2010).

Para ver mais white papers, consulte os white papers da coluna "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, o que eu realmente quis dizer foi gerenciamento de tarefas... Ai caramba, precisamos de tudo isso", é um grito de guerra que ouço com frequência. Não é a falta de definições desses três conceitos que causa a confusão, são suas semelhanças.

As pessoas que trabalham com TI há muitos anos tendem a ver as coisas do ponto de vista técnico e, às vezes, isso não é de muita utilidade. Se analisarmos os dados com base no Gerenciamento de portfólio, no Gerenciamento de projeto e no Gerenciamento de tarefas, eles podem ser bem parecidos. Há um campo de ID, um campo de descrição e uma data de início e de término em todos os três. Assim, vincular todos esses três deve ser natural.

Talvez não.

Vamos examinar 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

As pessoas podem querer dizer muitas coisas diferentes por "gerenciamento de portfólio", mas o significado mais comum provavelmente é seleção e indicação de prioridade do projeto. Os princípios basicamente afetam todas as pessoas na organização, mas o processo é de grande interesse para executivos sênior. O gerenciamento começa com certas restrições, como um orçamento total disponível, e uma necessidade de responder à pergunta "o que podemos e devemos realizar com essa quantia de dinheiro?" Se o processo de gerenciamento de portfólio estiver suficientemente amadurecido, essa análise poderá incluir não apenas as ideias novas, mas também projetos existentes.

Painel mostrando o status de vários projetos

Para criar um processo de seleção e definição de prioridade de portfólio, a gerência deve entender quais critérios comerciais conduzem a empresa e concordar com antecedência sobre as métricas que serão consideradas ao examinar projetos novos e existentes. O retorno sobre o investimento deve ser uma métrica importante? Talvez devamos considerar os efeitos sobre a satisfação do cliente, ou retenção de equipe, ou ainda o alinhamento com os objetivos estratégicos. Quaisquer que sejam as métricas principais, o gerenciamento deve ponderar cada iniciativa de projeto com uma visão de como esse projeto pode avançar com relação a esses objetivos e comparar cada projeto com iniciativas alternativas nas quais o dinheiro pode ser gasto.

Esse é um processo altamente analítico, mesmo que seja feito apenas na cabeça de alguém. Certamente é altamente analítico quando você usa o software de gerenciamento de portfólio de projetos. Mesmo quando a análise do software chega em um relatório ou exibição, quase sempre há alguma supervisão no nível de gerenciamento com base na qual uma decisão final sobre as prioridades é feita. Quando isso é concluído, os resultados finais devem ser transmitidos às pessoas que realizarão o gerenciamento de cada um dos projetos. Essas decisões terão o efeito de financiar alguns projetos e outros não, disponibilizar recursos como prioridade alta para alguns projetos e para outros não e avançar o cronograma de alguns projetos e atrasar o de outros.

Gerenciamento de projeto — de cima para baixo e de baixo para cima

Após a aprovação de um projeto, ele entra em um território completamente diferente. Agora nos concentraremos na perspectiva mais clássica do agendamento do projeto. Agora temos que realmente construir aquilo que descrevemos em nossa justificativa comercial antes da aprovação.

Um gerente de projetos começa pensando em termos de escopo do projeto e produtos finais. O gerente de projeto conhece o produto final que deve ser criado, seja ele um software ou um prédio pronto para ocupação. É preciso pensar nas principais fases do projeto e criar uma estrutura de detalhamento do trabalho.

Fases principais de um projeto representadas em um gráfico

Cria-se um caminho crítico de etapas lógicas necessárias para a conclusão do projeto. O gerente de projetos também sabe que será responsável pelo cronograma produzido e, portanto, consulta vários especialistas sobre o projeto. O gerente de projetos cria uma exibição de baixo para cima do projeto examinando tarefa por tarefa e resumindo essas tarefas até as fases do projeto e, eventualmente, até o próprio projeto. Neste momento, o gerente de projetos também pode começar a alocar recursos por qualificação, departamento ou até mesmo por nome. Esses recursos podem ter custos associados a eles. O resultado do cálculo da duração das tarefas, dos recursos necessários e do preço por hora nos dá uma estimativa de baixo para cima do projeto.

Até aqui tudo bem.

Modo de exibição do gráfico de Gantt de um projeto

Mas quando examinamos a abordagem de cima para baixo do processo de seleção de portfólio do projeto, houve um custo também. Na verdade, o custo estimado do projeto era parte da justificativa comercial que o gerenciamento considerou ao aprovar o projeto. Se estivermos obtendo a estimativa de baixo para cima do projeto apenas do conhecimento combinado dos especialistas no assunto, o que eles usaram para a seleção do projeto na sala da diretoria?

É uma boa pergunta. Em algumas organizações, o projeto terá uma estimativa aproximada do departamento de projetos a fim de 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 essas duas abordagens é que elas exigem esforço. Uma estimativa completa pode exigir muito esforço e o projeto ainda precisa ser aprovado para receber o financiamento. Assim, em muitas organizações, alguém do gerenciamento simplesmente faz uma estimativa de quais serão os custos do projeto.

Portanto, o processo parece todo integrado, mas pode haver um pouco de contradição. O que vem primeiro, o trabalho para fazer a estimativa ou a seleção do projeto a fim de poder gastar um tempo no projeto?

Além disso, o que acontece 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 dentro do tempo ou do orçamento estimado pelas pessoas que selecionaram o portfólio, haverá um conflito.

Talvez você pense que o natural seja reunir o gerenciamento sênior e apenas discutir o problema, mas há várias situações que não são tão fáceis quanto parecem.

Em primeiro lugar, o comitê de seleção de portfólio raramente é a equipe de gerenciamento de projeto. Membros da equipe de gerenciamento sênior do projeto quase sempre são incluídos no comitê de seleção de portfólio, mas o grupo em si é geralmente formado por executivos sênior que consideram um desafio organizar o tempo para se reunirem. Em segundo lugar, o comitê de seleção pode se reunir de forma irregular. Portanto, reuni-los novamente para discutir todas as ramificações de um custo incompatível de um projeto versus a estimativa pode ser um grande desafio. Por fim, em algumas culturas corporativas, dizer ao executivo sênior que sua estimativa sobre o cronograma e o orçamento do projeto está completamente errada não é considerada uma ação promissora para a carreira.

Gerenciamento de tarefa: uma abordagem de baixo para cima

Quando pensamos em gerenciamento de tarefas, temos a tendência em pensar de forma muito operacional, e que com frequência nos leva à nossa agenda diária e a um produto como o Outlook.

Visualização de uma lista de tarefas

Agora estamos trabalhando em um nível individual ou de membro da uma equipe pequena. Não vemos as tarefas no contexto. Vemos as coisas com as quais nos comprometemos ou talvez as coisas que pedimos a um membro da equipe para se comprometer. Essa não é uma visão analítica. Há tarefas a serem realizadas e a pessoa se comprometeu a realizá-las.

Basicamente, o gerenciamento de tarefas é bastante simples. Você executa a tarefa e, quando a termina, informa à pessoa que atribuiu a tarefa a você de que foi concluída. Toda a funcionalidade para isso já está no Outlook.

O prejuízo dos dados semelhantes

Há um ditado que diz: “se há fumaça, há fogo". Isso é verdadeiro para a fumaça, mas nem sempre é válido para dados baseados em tarefas.

Vamos considerar estes três níveis de dados orientados a projetos:

  • No nível de 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 de 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.

  • No nível de gerenciamento de tarefa, temos uma tarefa, e as informações sobre a 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.

Elas parecem iguais, mas, na verdade, a perspectiva dos dados faz com que cada um desses registros comuns sirva a uma finalidade muito diferente.

Frequentemente recebo a seguinte pergunta: "posso mover dados do modo de exibição de portfólio para o modo de exibição de projeto e depois para o Outlook e vice-versa".

A resposta curta para essa pergunta é: "sim".

Porém, em nossa firma, temos um mantra que repetimos para nós mesmos quando estamos dando conselhos técnicos: "não me diga como fazer isso, diga-me porque você deve fazer isso."

  1. Para firmar a ideia, imagine este exemplo. Criamos um ambiente totalmente integrado. Na extremidade superior da escala, temos uma lista de projetos organizados por portfólio. Selecionamos esses projetos e integramos ainda mais, acompanhando-os após a ativação em projetos ativos do sistema de EPM. Para fazer isso, usamos uma funcionalidade já disponível para mover as definições de projeto e de fase do lado do portfólio de nosso sistema integrado para o lado do projeto do sistema. Os dados parecem idênticos.

  2. Agora, em nosso sistema de gerenciamento de projetos corporativos fazemos uma definição mais detalhada, usando as fases originais da definição de portfólio obtida de cima para baixo. Isso permite que o resumo seja atualizado no sistema de portfólio quando atualizamos nossos projetos. Criamos várias tarefas e atribuímos muitos recursos. Agora fazemos uma análise de redistribuição de recursos para determinar nossa capacidade entre vários projetos.

  3. Usamos nossas atribuições de recursos para enviar dados de tarefa e de atribuição a cada usuário como um evento de calendário ou tarefa do Outlook. Os usuários não precisam mais acessar um "sistema de gerenciamento de projetos". Agora eles podem ver os dados em suas agendas diárias. Os dados têm a mesma aparência que apresentam na lista de projetos e são vinculados ainda mais acima no fluxo do projeto, no modo de exibição de portfólio.

  4. O progresso dessas tarefas e a disponibilidade do Outlook são movidos do indivíduo de volta para o sistema de gerenciamento de projetos com as estimativas de conclusão desse trabalho. Os dados têm a mesma aparência apresentada nos outros dois sistemas, portanto, mover os dados é relativamente fácil.

Criar um sistema desse tipo tecnicamente é bastante simples usando as ferramentas disponíveis atualmente, além de um pouco de configuração e desenvolvimento. E ele funcionaria de forma incrível.

Recebemos pedidos regularmente por esse tipo exato de estrutura. Mas, mesmo que possamo criá-lo, devemos fazer isso?

Imagine que no nível da tarefa, uma pessoa tira a manhã para uma visita emergencial a um dentista e atualiza seu Outlook informando que não estará disponível nesta manhã. Isso é uma má notícia para ela, mas os efeitos em cascata para o projeto podem ser enormes. Agora, o sistema do projeto calcula que a tarefa agendada para ser executada nesta manhã não será concluída hoje; será concluída somente amanhã ao meio-dia. Ele obedientemente analisa o caminho crítico e todas as tarefas abaixo desta e as atrasa quatro horas. Talvez centenas de tarefas foram afetadas. O resultado pode ser o atraso da data de término do projeto em meio dia. Outros projetos também serão afetados, uma vez que outras pessoas que estão trabalhando nesse projeto terão suas tarefas reorganizadas. O próprio modo de exibição de portfólio avança alguns pixels.

Se imaginarmos isso em tempo real, o problema é ampliado. Centenas ou milhares de pessoas estão fazendo alterações durante o dia, e o modo de exibição de EPM, o modo de exibição de redistribuição de recursos e o modo de exibição de portfólio mudam constantemente com os efeitos dessas mudanças.

Na verdade, isso não acontece. Em primeiro lugar, a pobre paciente voltará ao seu posto ao meio-dia e talvez trabalhe mais algumas horas após o expediente para garantir que esse caminho crítico seja detectado e tudo volte ao normal pela manhã.

Além disso, apesar de os dados terem a mesma aparência, eles nunca são integrados dessa maneira, justamente por causa desse efeito.

Contexto de dados: a perspectiva é importante

Quando examinamos os dados, o contexto dos dados é essencial. Os dados que talvez pareçam os mesmos de um esquema registro a registro são usados para fins bastante diferentes com base na perspectiva do aplicativo.

Em um modo de exibição de portfólio de cima para baixo, tomamos decisões estratégicas sobre onde colocar nossos recursos a fim de maximizar nosso retorno sobre o investimento. Talvez tomemos decisões que um gerente de projetos não tomaria. Em minha própria organização, às vezes escolhemos projetos completamente fora de nosso conjunto de qualificações. Mesmo sabendo que podemos ser ineficientes, fazemos isso porque queremos melhorar essas mesmas qualificações. O retorno sobre o investimento não foi uma instalação eficaz, mas sim os instaladores treinados. Essa é uma visão analítica.

Em uma visão de projeto tática, estamos tomando decisões operacionais sobre como obter a melhor produtividade de nosso pessoal e como concluir nossos projetos de forma mais rápida e eficiente possível. O olho de um gerente de projetos está sempre voltado para o futuro. O que aconteceu no passado interessa ao gerente de projetos apenas na medida que melhora sua visão do futuro. Essa também é uma visão altamente analítica.

Em uma visão de gerenciamento de tarefas como uma agenda, não somo analíticos. Uma agenda é um sistema de comprometimento. Prometemos a nós mesmos ou a outras pessoas que faremos algo específico em um determinado momento. Isso pode se ajustar à visão analítica. E talvez não possa.

Misturar essas perspectivas e contextos sem entender o impacto pode gerar caos.

De cima para baixo ou de baixo para cima?

Normalmente, não há uma resposta certa. Alguns aspectos do seu sistema de gerenciamento de projetos realmente precisam vir de baixo para cima. Afinal de contas, são os indivíduos que desenvolverão o projeto, qualquer que seja o assunto. Mas algumas decisões são, e devem ser, tomadas a partir de cima e são, como necessidade, de cima para baixo.

Quando você mantém as distinções de funcionalidade de cada nível do paradigma de gerenciamento do projeto, fica mais claro ver se alguns desses sistemas devem realmente ser integrados ou não. Se durante o processo e consideração de um nível for verificado que não há benefício direto na integração total com outro nível, a integração não será a melhor jogada. É importante analisarmos como essa integração funcionaria em um contexto real e se a frequência e os detalhes de um nível proporcionam valor ao outro.

Diagrama mostrando um fluxo de trabalho

Se, por exemplo, um comitê de orientação se encontrar apenas uma vez a cada trimestre para tomar decisões muito importantes sobre quais projetos avançar e quais não, qual será o benefício de atualizar a visão desse comitê todos os dias, toda semana ou todos os meses?

O algoritmo de redistribuição de recursos do gerenciamento de projetos corporativos realmente precisa ver a consulta odontológica de uma pessoa, ou basta saber a disponibilidade aproximada dessa pessoa?

Ainda, se pudéssemos enviar uma atribuição diretamente à agenda ou ao quadro de horários de uma pessoa, isso economizaria alguns minutos todos os dias sem precisar acessar um sistema e uma interface diferente para ver os mesmos dados?

Portanto, de cima para baixo é bom em determinadas circunstâncias, e de baixo para cima é bom em outras. Você precisa examinar sua própria situação para ver onde a integração dessas ferramentas e conceitos pode compensar antes de vinculá-los.

Sobre o autor

Chris Vandersluis é presidente e fundador da HMS Software, com base em Montreal, Canadá, um parceiro certificado da Microsoft. Ele é formado em Economia pela McGill University e tem mais de 30 anos de experiência em automação de sistemas de controle de projetos. Membro do Project Management Institute (PMI), ele participou da fundação dos capítulos de Montreal, Toronto e Quebec do Microsoft Project Users Group (MPUG). As publicações para as quais Chris já escreveu incluem a Fortune, a Heavy Construction News, a Computing Canada e a PMNetwork, além de ser colunista regular da Project Times. Professor de Gerenciamento Avançado de Projetos na McGill University, frequentemente dá palestras sobre as funções da associação de gerenciamento de projetos na América do Norte e no mundo. A HMS Software é a fornecedora do sistema de controle de horas orientado para projetos TimeControl e é Parceira de Soluções de Projetos da Microsoft desde 1995.

Chris Vandersluis pode ser contatado pelo email: chris.vandersluis@hms.ca.

Se quiser ler mais artigos de Chris Vandersluis relacionados a Gerenciamento de Projetos Corporativos (EPM), consulte o site sobre diretrizes de Gerenciamento da HMS (http://www.epmguidance.com/?page_id=39).

Expanda suas habilidades
Explore o treinamento
Obtenha novos recursos primeiro
Ingressar no Office Insider

Essas informações foram úteis?

Obrigado por seus comentários!

Agradecemos pelos seus comentários! Parece que pode ser útil conectar você a um de nossos agentes de suporte do Office.

×