Tempo de leitura: 11 minutos
No passado, as áreas de negócio das empresa costumavam trabalhar internamente isoladamente, comunicando-se por meio de interfaces pouco definidas. Hoje em dia é necessário um pensamento e uma atuação cada vez mais abrangentes e holísticos.
Consequentemente, mais e mais áreas de negócios estão envolvidas em projetos. Além disso, a Revolução Digital requer, em particular, cenários de TI, significativamente sólidos, que são desafiados repetidamente ou pelo menos ficam sob pressão devido às rápidas mudanças nos modelos de negócios, processos e nos próprios projetos.
Isso cria uma variedade de desafios:
- Muitas empresas ou divisões corporativas simplesmente não têm transparência sobre quais projetos com quais metas foram solicitadas ou aprovadas e quais projetos em andamento estão em que status.
- No caso de um grande número de projetos paralelos, muitas vezes não está claro quais áreas, processos e sistemas de TI são afetados por qual projeto.
- Devido à sobreposição de atividades de rotina e projeto, o gerenciamento geral de recursos está se tornando cada vez mais exigente. O mesmo se aplica aos crescentes requisitos de conformidade.
- Priorizar projetos em andamento e recém-aplicados requer um conhecimento preciso de todo o cenário do projeto.
- Devido às diretrizes às vezes existentes, apenas projetos com um determinado volume de investimento (por exemplo, R$ 50.000) precisam passar por um processo de aprovação. Isso geralmente significa que um projeto maior é dividido em vários projetos, cada um deles abaixo do limite (por exemplo, R$ 48K). Não é fácil para a alta gerência identificar esses “truques” e tomar contramedidas, se necessário.
- A falta de padronizações, processos e sistemas geralmente significa que há muito esforço no novo design em solicitações de projetos e relatórios de status e que decisões significativas, rápidas e compreensíveis não são possíveis.
A seguir, explique o que é o Gerenciamento de Portfólio de Projetos (PPM) e como o PPM pode abordar e resolver esses e outros desafios sem muito esforço.
O que é PPM?
PPM é a abreviação de Project and Portfólio Management.
O objetivo principal do PPM na empresa é criar um entendimento e um nível de informações comuns sobre o cenário atual e futuro dos projetos da organização. Isso deve ajudar a garantir que vários projetos paralelos possam ser implementados com rapidez e sucesso e que eles não se atrapalhem ou que busquem objetivos opostos e conflitantes.
Por meio de solicitações claras e enxutas, canais de aprovação e informações, o PPM aumenta a eficiência de custos e diminui o número de erros, fazendo com que os requisitos importantes de conformidade sejam atendidos.
Por exemplo, pode-se garantir que os projetos sejam sempre avaliados sobre a ótica da estratégia empresaria. Também permite que redundâncias, dependências entre projetos e possíveis problemas sejam rapidamente identificados.
O PPM elaborada uma camada de transparência que fornecer aos órgãos de decisão todas as informações necessárias em tempo hábil.
PPM versus Gestão de Programas e projetos.
Gerenciamento de portfólio de projetos, gerenciamento de programas e projetos são frequentemente usados de forma unificada. No entanto, é aconselhável fazer uma definição clara e uma separação.
Se houver vários projetos na organização, todos servindo para atingir um objetivo comum e abrangente e talvez até influenciar um ao outro, pode fazer sentido combinar esses projetos em um programa abrangente.
Como regra, os projetos individuais continuarão sendo controlados pelo gerenciamento de projetos independente. O gerenciamento do programa garante que as influências e interdependências mútuas dos projetos sejam levadas em consideração adequadamente.
No entanto, isso não interfere no gerenciamento operacional dos projetos. A exceção pode ser o fato de, por exemplo, um gerente de projeto júnior liderar um projeto pela primeira vez e ser apoiado ativamente por um gerente de programa experiente.
Para escalações, deve ser regulamentado se isso é relatado diretamente ao comitê de direção pelo gerente de projeto ou se isso deve ocorrer no nível do programa.
PPM versus Gestão Operacional de Projetos
A conexão entre o PPM e o gerenciamento operacional do projeto consiste em um planejamento de alto nível e relatórios regulares de status, incluindo gerenciamento de riscos e escalações. O PPM tem um caráter abrangente e não deve, em circunstância alguma, ser sobrecarregado com os muitos detalhes do gerenciamento operacional do projeto.
Embora alguns fabricantes de sistemas recomendem o uso de ferramentas integradas de gerenciamento de projetos e PPM, eu não recomendaria isso. Existem duas razões principais para isso.
Por um lado, os grupos-alvo para processos e informações são fundamentalmente diferentes nos dois níveis. Os “clientes” típicos do PPM estão no nível de gerenciamento executivo ou de divisão. O gerenciamento de projetos geralmente é relevante para os gerentes de projetos operacionais.
Por outro lado, é aconselhável assumir claramente a responsabilidade pelos gerentes de projeto, separando os sistemas gravando os relatórios de status no sistema PPM e não podendo confiar na consolidação automática dos sistemas subjacentes. Por mais tentador que isso possa parecer, neste caso, a etapa manual faz mais sentido. É óbvio que, por exemplo, o atraso de uma atividade individual no plano detalhado do projeto de um subprojeto torna o semáforo vermelho, mas o impacto no projeto geral pode ser completamente irrelevante. Uma consolidação automática definiria logicamente todo o projeto para vermelho.
Os gerentes de projeto devem considerar muito bem quais dados são relevantes para o relatório de status e devem estar cientes de que são responsáveis por esses dados.
PPM e PMO
Às vezes, o gerenciamento de portfólio de projetos e o escritório de gerenciamento de programas / projetos são equivalentes, o que não é necessariamente um problema.
É importante apenas que as tarefas e responsabilidades sejam claramente definidas. Como já mencionado acima, o PPM geralmente ocupa pouco ou nenhum cuidado com o gerenciamento operacional de projetos. Um PMO, por outro lado, geralmente apoia os gerentes de projeto em questões operacionais, treina a equipe júnior, se necessário, e apoia os gerentes de projeto no controle do projeto.
PPM e agilidade
Muitas vezes me perguntam que impacto o aumento da agilidade tem no gerenciamento de portfólio de projetos. A resposta é simples: a agilidade não afeta o PPM.
Isso pode ser melhor explicado usando a definição de escola de um projeto, porque, como o nome sugere, o PPM é sobre projetos e não sobre negócios do dia-a-dia. E os projetos são caracterizados pelo fato de terem um objetivo claro, serem limitados no tempo e terem uma organização separada da linha – a organização do projeto.
Do ponto de vista do PPM, não importa se esses projetos são realizados usando o método cascata clássico, ágil ou híbrido. Em todos os casos – também no ágil e híbrido – existem as propriedades acima mencionadas de um projeto. Mesmo um projeto ágil não deve ser configurado sem uma meta, orçamento, recursos e cronograma.
Do ponto de vista do PPM, não importa se esses projetos são realizados usando o método cascata clássico, ágil ou híbrido.
Torna-se desafiador, quando empresas inteiras ou pelo menos divisões corporativas são gerenciadas de maneira ágil, por exemplo, através da OKR (Objetivos e Principais Resultados). Trabalhar em unidades lideradas pela OKR costuma parecer trabalho de projeto, mas há uma diferença crucial:
Não há limite de tempo com começo e fim. As unidades organizacionais em questão são, portanto, as chamadas unidades de linha e não as unidades de projeto.
Implementação PPM
A seguir, é mostrado um exemplo de como um processo PPM pode ser implementado. A abordagem introduzida já foi introduzida várias vezes por mim em empresas de diferentes setores e tamanhos, com pequenos ajustes. O esforço é muito gerenciável em comparação com o valor agregado.
Devido ao fato de que o PPM deve ser separado do gerenciamento operacional do projeto, a complexidade do suporte adequado ao sistema por meio de uma ferramenta ou implementação especializada de PPM com base em uma plataforma existente (por exemplo, o NetProject) permanece dentro de limites.
A medida em que o mapeamento do sistema como um todo do processo faz sentido depende, é claro, do tamanho e da estrutura da empresa e do número ou variedade do cenário do projeto. Pode fazer sentido introduzir seus próprios PPMs para áreas ou países individuais da empresa e um PPM de nível superior para projetos “grandes”.
A introdução do gerenciamento de portfólio de projetos geralmente sempre começa com um inventário. Inclui quantos e quais projetos estão atualmente na fase de implementação e qual é o respectivo status. Deve-se considerar imediatamente se qualquer tipo de projeto pode ser criado, por exemplo, B. de acordo com certos tipos de projetos de TI (infraestrutura, desenvolvimento de software etc.) ou de acordo com tópicos técnicos (vendas, finanças, etc.) ou de acordo com aspectos regionais (país, região etc.).
Além disso, o número e o manuseio de “idéias de projetos” devem ser analisados. O esforço que é “rastejante” em algumas organizações, ou seja, sem processos compreensíveis, a discussão e a avaliação das idéias do projeto podem ser bastante consideráveis.
Aliás, o inventário inicial não deve ser subestimado. É incrível quantos executivos de topo não podem dizer ad hoc, quantos projetos estão atualmente em que estágio e qual é o status deles. E isso apesar do fato de ser frequentemente um investimento de milhões.
Assim que o processo PPM real é projetado, uma especificação aproximada ajuda. Em resumo, esse requisito pode ser representado da seguinte maneira:
Da ideia do projeto à proposta do projeto
Independentemente de as idéias de projetos serem provenientes de qualquer área de negócios, de discussões com clientes ou fornecedores ou de departamentos de inovação dedicados, elas definitivamente devem ser registradas de maneira estruturada e avaliadas de acordo.
Por mais trivial que pareça, as idéias enviadas devem primeiro ser verificadas quanto à inteligibilidade. Muito trabalho pode ser evitado se os geradores de ideias precisarem se dar ao trabalho de formular suas intenções de forma que possam ser rapidamente verificados quanto a duplicatas ou idéias que já foram rejeitadas.
Além disso, uma diretriz clara deve ser definida, a partir de qual tamanho aproximado se fala de um projeto em potencial (por exemplo, esforço estimado e quantia de investimento> € 25K). Dessa forma, a multiplicidade de medidas, que podem ser implementadas com um esforço de apenas algumas pessoas por dia, pode ser atribuída à avaliação direta e possível implementação nas respectivas áreas especializadas. Dessa forma, eles podem aprender com o tempo quanto recursos e esforços devem ser planejados para a implementação regular de tais medidas.
Como já indicado, após essa primeira pré-seleção, as idéias “maiores” restantes devem ser verificadas para ver se elas já foram enviadas e como foram tratadas, se necessário. Se, por exemplo, uma ideia idêntica ou semelhante já tiver sido enviada e até transferida para um projeto, ela deverá ser comunicada aos fornecedores da ideia de acordo.
Qualquer que seja o motivo da rejeição de uma ideia, a própria rejeição e as razões devem ser documentadas e comunicadas ao respectivo fornecedor da ideia. Como já mencionado, você pode reagir com rapidez e eficiência a idéias repetidas.
Idealmente, essa pré-seleção é realizada, assim como a avaliação subsequente das idéias consideradas interessantes por um Comitê de Portfólio de Projetos (PPB) ou por outra unidade que lide explicitamente com esses tópicos.
Se uma ideia é geralmente interessante, a criação de uma proposta de projeto é comissionada. Em contraste com a ideia do projeto, uma proposta de projeto contém consideravelmente mais informações. Dependendo do caso individual, pode fazer sentido até manter propostas de projetos de tamanhos diferentes. Dependendo do tamanho, criticidade e complexidade em potencial, diferentes documentos de aplicação podem ser solicitados.
De qualquer forma, eu recomendaria manter as propostas de projeto o mais enxutas possível. Solicitações de projeto prolongadas tentam você a preparar muitas informações de tal maneira que elas tendem a causar confusão, em vez de fornecer uma base sólida para as decisões.
