Gerenciamento de Programas – Superando obstáculos para o sucesso

O Gerenciamento de Programas formal está se tornando uma iniciativa mais difundida para  ajudar a melhorar processos de gerenciamento de projetos simultâneos. Embora o gerenciamento de múltiplos projetos por um mesmo dispositivo já é uma prática antiga, o gerenciamento de programas tornou-se mais reconhecido pela consistência eficaz que traz ao processo. O reconhecimento de tal método, oficialmente, como um processo estruturado, fornece aos gerentes de projeto e programas um conjunto de normas e controles que contribuem para o sucesso.

Este artigo não é sobre o que é gerenciamento de programas.  Este artigo é, por sua vez, um texto sobre experiências reais que podem contribuir para uma melhor compreensão de como o gerenciamento de programas podem ser realizado com sucesso.

Enquanto este artigo sugere que escritórios formais de programas com boa comunicação em projetos e monitoramento de processos ajudam a evitar os desafios normalmente encontrados, ele também pretende descrever os desafios mais comuns e soluções apropriadas que geralmente existem em uma organização sem um forte controle de escritório de programas.

Gerenciamento de programas

Os programas são compostos por vários projetos individuais, cada um com um gerente e uma equipe que é responsável pela entrega de um produto seguindo os padrões de gerenciamento de projetos.

Os projetos são agrupados em um programa porque uma organização percebe que cada um dos projetos existe para alcançar o mesmo objetivo estratégico em benefícios organizacionais no geral.

Todos e quaisquer projetos que fazem parte de um programa podem ser muito bem sucedidos individualmente e dentro do programa. No entanto, o programa, como um todo, pode falhar.

O motivo mais recorrente para essa falha é não ver o programa como um projeto em si e não construir um forte processo de gerenciamento de integração de cada um dos sub-projetos dentro do programa.

É muito fácil combinar vários projetos em um único cronograma, identificar as dependências cruzadas de projetos, gerenciar esse único cronograma como o cronograma do programa, e ainda falhar.

Isso porque um programa não é simplesmente um conjunto de projetos que são combinados para um único objetivo. Um programa é desafiador pelo fato de que cada um dos projetos independentes são geralmente vistos e gerenciados como tal – individualmente.

Este ponto de vista “individual” dos projetos é um fenômeno natural. Cada gerente de projeto é responsável por assegurar a entrega para a qual ele ou ela é atribuído.

Geralmente, existe pouco interesse ou tempo gasto na preocupação com outros projetos do programa. Isso acontece não porque cada gerente de projeto não é consciente ou atento aos outros projetos.

Na maioria dos casos, é simplesmente porque o gerenciamento de programas não foi suficientemente formalizado, documentado e comunicado a equipe do projeto para permitir que cada equipe entendesse como elas se encaixam no programa global.

Gerenciamento de programas x projetos

Os processos do Um Guia de Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) foram, historicamente, bem aplicados em projetos.

O gerenciamento de programas e suas respectivas equipes por outro lado, geralmente sofrem pela falta dos mesmos processos. As equipes de projetos são frequentemente consideradas como um modelo de estrutura organizaciona funcional, guardiães ou auditores.

Estas equipes geralmente não são consideradas como tendo os tipos detalhados de estruturas e processos no lugar, como os projetos têm. Elas são geralmente vistas como gerentes de gestão e não de produção.

O Padrão para Gerenciamento de Programas do PMI descreve como essas hipóteses não são o caso anteriormente discutido.

Ele explica o gerenciamento de programas como tendo três temas:

• Gerenciamento de benefícios;
• Gerenciamento das partes interessadas;
• Governança de programas;

Os dois primeiros temas são geralmente mais fáceis de atingir e frequentemente seguem processos para gerenciamento de benefícios e das partes interessadas de uma forma semelhante à forma como os projetos gerenciam esses processos.

A governança de programas, no entanto, geralmente torna-se um desafio, devido à tendência dos projetos separados preferirem governarem a si mesmos.

Eles tornam-se particularmente mais difíceis de serem gerenciados quando se trata dos processos de conhecimento nas áreas de Gerenciamento dos Recursos Humanos, Gerenciamento da Qualidade, Gerenciamento das Comunicações e Gerenciamento dos Riscos.

Enquanto várias, se não todas, das dez áreas de conhecimento de gerenciamento de projetos são aplicáveis ao gerenciamento de programas, este artigo concentra-se nos princípios e técnicas relevantes para as quatro áreas específicas de conhecimento citadas acima, como elas lidam com o gerenciamento de programas aperfeiçoado e especificamente em relação à governança de projetos e programas.

DENTRO DE UMA EMPRESA É, NORMALMENTE, DIFÍCIL PARA OS FUNCIONÁRIOS DEDICAREM SEU TEMPO A UM PROJETO, MESMO SE DESIGNADOS EM TEMPO INTEGRAL, POIS É DIFÍCIL NÃO SE DESVIAR POR “TRABALHOS DO DIA A DIA.”

DENTRO DE UM PROGRAMA, É AINDA MAIS COMPLICADO QUANDO UM MESMO INDIVÍDUO É REQUERIDO PARA TRABALHAR EM VÁRIOS PROJETOS AO MESMO TEMPO.

Gerenciamento dos Recursos Humanos – Desafios e Soluções

Um dos maiores desafios para o gerenciamento de programas é o gerenciamento dos recursos. Este desafio está geralmente relacionado ao gerenciamento do tempo, relações hierárquicas e interação de equipe.

Dentro de uma empresa é, normalmente, difícil para os funcionários dedicarem seu tempo a um projeto, mesmo se designados em tempo integral, pois é difícil não se desviar por “trabalhos do dia a dia.”

Dentro de um programa, é ainda mais complicado quando um mesmo indivíduo é requerido para trabalhar em vários projetos ao mesmo tempo.

Por exemplo, uma organização pode ter apenas um administrador de banco de dados, ou um responsável pela segurança, um especialista em controle de mudança, um gerente de departamento, etc.

E enquanto esses indivíduos podem, frequentemente, dar suporte mais facilmente à organização ao mesmo tempo em que eles executam tarefas relacionadas ao projeto, torna-se extremamente difícil conciliar tais funções, quando eles são designados como participantes de igual importância em vários projetos dentro do programa, todos concorrendo pela contribuição individual.

Em segundo lugar, os membros da equipe, organizacionalmente, possuem relações hierárquicas que podem ter vários supervisores, incluindo gerentes de projetos e membros da equipe de gerenciamento organizacional que têm seus próprios interesses departamentais a considerar.

As relações cruzadas e os impactos de equipes de múltiplos projetos concorrendo e/ou competindo pela atenção e adesão da gerência tornam-se mais complexas.

Terceiro, as interações entre equipes são geralmente mais desafiadoras. As equipes do projetos dentro dos programas tendem a se isolar às vezes. Elas fazem isso para “proteger seu território” dos controles gerais do programa.

Elas também o fazem para formarem relações mais próximas dentro da equipe que são simplesmente mais fáceis de gerenciar do que as relações cruzadas com outras equipes do projetos.

Geralmente, outras equipes de projeto têm objetivos, produtos, prazos, orçamentos e atenção completamente diferentes do que outra equipe do projeto. Isso geralmente leva a essa postura isolacionista.

Torna-se necessário, então, no nível de um programa, prestar maior atenção aos ativos de processos dos Recursos Humanos que formam o plano do programa. Essas ações ajudarão a trazer sucesso:

• A formalização e validação de organogramas do projeto de forma individual, como parte do organograma global do programa, é importante. Esta estrutura organizacional também precisa incluir equipes de gerenciamento e entidades externas.

• A criação de descrições detalhadas de cargos que descrevem as atividades do programa, bem como as do projeto, precisam ser incluídas. Os cargos devem ser descritos de uma forma que permita ao indivíduo compreender que seu papel e compromisso podem ser diferentes dependendo da forma que eles interagem dentro dos vários projetos.

• Criação de um gráfico de responsabilidades (RACI) que inclua a dimensão do programa em alinhamento com a responsabilidade do projeto. Um exemplo é mostrado na figura  mais abaixo.

• Regras básicas precisam ser documentadas em nível de programa e se tornarem parte do processo de revisão de qualidade do ponto de vista de ativo organizacional. Uma boa maneira de assegurar a uniformidade nesta técnica é prover o gerenciamento de programas como um processo organizacional de tempo integral ou mudar o gerenciamento de recursos. Este papel é fundamental não somente no gerenciamento de recursos, mas em termos de comunicação dentro e fora das equipes do programa.

• O processo/mudança organizacional de gerenciamento dos recurso também pode ser importante para garantir que as equipes se “encontrem e se acolham” numa base regular, através de atividades planejadas, tanto profissional como pessoalmente. Um programa de recompensas, como parte desse processo também é eficaz, uma vez que cada membro da equipe está ciente de como o programa funciona e quais os comportamentos e resultados são esperados.

• A comunicação antecipada e repetida das expectativas do nível do programa e a relação com os benefícios do projeto é crucial. Cada membro da equipe deve ser constantemente lembrado de que eles são parte de um esforço organizacional maior.

• O mapeamento completamente documentado de pessoas e de seus rendimentos para as realizações dos benefícios do projeto/ programa devem ser compartilhados. Os recursos do programa precisam participar de reuniões do programa ou eventos para ajudar ainda mais esse objetivo. Essas reuniões não devem ser limitadas apenas aos gerentes de projeto, mas devem incluir todos os níveis de participantes do projeto quando benéfico

Gerenciamento da Qualidade – Desafios e soluções

As equipes de projeto, especialmente na entrega de produtos diferentes utilizando diferentes ferramentas, geralmente, consideram-se livres para ignorar as diretrizes ou regras do programa.

A postura isolacionista descrita sob os desafios do gerenciamento dos recursos humanos, geralmente, contribui para essa visão.

Em muitos casos, as equipes de projeto, especialmente se compostas de fornecedores terceirizados, ficam bastante confortáveis com a sua própria maneira de executar um projeto e não têm interesse em concordar com o “modo do programa”.

Equipes que possuem uma história juntos, seja atuando em grupos dentro da organização ou como equipes de produto, se veem como especialistas em seus próprios processos. Embora tudo isso possa ser verdade, quando vistos de uma perspectiva do programa, a entrega e a qualidade do processo podem estar em risco.

Os padrões de qualidade, especialmente quando relacionados a processos do projeto e entregas, precisam ser mais altamente padronizados nos programas.  Reconhecendo que todos os projetos contribuem para as expectativas de benefícios gerais do programa, os padrões de qualidade precisam ser consistentes através dos projetos para que esses benefícios possam ser igualmente entregues.

Entregas que parecem diferentes podem gerar confusão para o usuário final. Processos tais como testes, manuais de usuários, etc., que são desenvolvidos com modelos, abordagem, conteúdo e estilo diferentes criam níveis diferentes de qualidade.

Para garantir sucesso, os padrões de qualidade devem ser projetadas e documentadas em um nível suficientemente elevado de modo que elas possam ser facilmente mapeadas para as entregas e processos que contribuem para os benefícios esperados.

Um plano de qualidade do programa deve ser escrito durante o processo de iniciação do programa que identifica quais os padrões de qualidade que serão adotados, como eles serão aplicados e monitorados e como eles se conectam com os benefícios esperados.

Este plano deve servir como entrada para cada atividades do Grupo de Processos de Planejamento do Projeto (ver Figura 2).

Além do plano de qualidade, é, geralmente conveniente, configurar uma biblioteca de modelos e descrições de processos que são projetados de tal modo, que eles possam ser usados por qualquer equipe de projeto sem ter de redesenhar a ferramenta.

Por exemplo, um modelo de plano de teste que define os processos de teste esperados a serem aplicados a todos os projetos e como estes processos de testes são entrelaçados aos testes de programa, pode ser criado.

O uso de padrões, modelos, instruções, recursos, softwares e outros componentes deve ser considerado.  A biblioteca deve, também, servir como repositório do programa para todo o trabalho em progresso e resultados finais.

Ela deve ser organizada de forma que permita que tanto a documentação específica do projeto, como as normas de nível do programa sejam facilmente acessadas, armazenadas e empregadas.

A Figura 3 mostra um único exemplo de como uma biblioteca desse tipo pode ser projetada. Esta abordagem assume uma estrutura de alto nível baseada no programa global.

Dentro do Grupo de Processos de Execução, cada projeto tem seu conjunto individual de documentos e entregas de projeto.

Gerenciamento das Comunicações – Desafios e soluções

Geralmente, não é prestada a atenção requerida às comunicações do projeto visto que a maioria das equipes de projeto se concentram em finalizar, primeiramente, a “lista de tarefas”. A comunicação, portanto, tende a ser centrada em torno de reuniões de equipe, atualizações do comitê de direção e boletins informativos ocasionais.

Enquanto que isso é uma abordagem tipicamente limitante para as comunicações, ela também está presente em um nível do programa, quando vários projetos dentro do programa não somente funcionam dessa maneira, mas ainda excluem outros participantes do programa desses processos.

Esta comunicação está relacionada não apenas à comunicação das partes interessadas, mas à comunicação do programa/projeto relacionada a questões, status e outras comunicações.

As equipes de projeto tendem a documentar suas próprias reuniões, criar suas listas de questões e enviar e-mails para seus próprios membros.

Essas atividades têm um lugar. Mas, fora dessa abordagem, está a necessidade de compreender e comunicar como uma simples questão em uma equipe pode afetar outra equipe.

Ou como uma necessidade de um recurso em uma equipe é visto como algo normal, sem se comunicar com outras equipes caso exista conflitos de agendamento para esse mesmo recurso.

Em alguns casos, comunicações públicas em boletins informativos, sites da empresa, folhetos de propaganda, mensagens transmitidas em rádio e em outros lugares, às vezes podem impactar negativamente outro projeto dentro do programa sem que os iniciadores percebam.

Uma comunicação, em particular, pode enviar uma mensagem exatamente oposta a que uma equipe diferente está tentando passar, criando confusão para o leitor.

Do ponto de vista do programa, as comunicações devem ser deliberadamente formalizadas e reconhecidas como a única fonte de mensagens chave. A uma pessoa específica da equipe do programa deve ser atribuído um papel de comunicação.

Esse indivíduo precisa desenvolver o plano de comunicação à partir de uma perspectiva do programa e incluir comunicações específicas de projeto dentro desse plano.

O plano de comunicação do programa precisa ser projetado para posteriormente concentrar-se na comunicação relacionada com os benefícios originais do programa.

Ele precisa estrategicamente relacionar as contribuições de cada projeto e seus status de uma maneira a comunicar todos os benefícios para todas as partes interessadas. Esta forma de abordagem permite que o ouvinte ou o leitor capte uma mensagem de forma consistente.

Além disso, essas mensagens devem ser enviadas com tom, estilo e linguagem consistente para que o ouvinte reconheça-as facilmente ao longo do tempo. Isso contribuirá para menos confusão e interpretação errônea por parte do ouvinte.

O programa de comunicação focado tende, posteriormente, a ser percebido como mais “oficial” dentro das organizações.  Essas comunicações são, geralmente, associadas a um escritório formal de comunicações da organização, o que contribui para uma posição, em geral, mais proeminente.

Usando efetivamente essa vantagem, no entanto, significa que o principal as comunicações do programa devem trabalhar intimamente com cada uma das equipes de projeto para compreender completamente o seu papel, seus objetivos e seus resultados.

Isso permitirá que cada uma das equipes de projeto tenham sucesso ao comunicar o que é necessário sem se sentirem deixadas de lado.

Todas as equipes de projeto precisam ser treinadas a fim de considerarem as comunicações como um ponto crítico e sensível do processo ao longo do caminho para a conclusão do projeto. Sessões de orientação das equipes devem incluir a instrução específica de como as comunicações ocorrerão dentro do programa.

Uma cópia do plano de comunicação do programa deve ser dado a cada membro da equipe do projeto `a medida que seguem com o programa.

RELATÓRIOS PERIÓDICOS DE STATUS (SEMANAL, QUINZENAL) DEVEM SER PUBLICADOS POR CADA EQUIPE DE PROJETO UTILIZANDO UM FORMATO CONSISTENTE E CONSOLIDADO PELA EQUIPE DO PROGRAMA PARA AMPLA DISTRIBUIÇÃO.

Além disso, enquanto algumas comunicações do programa podem simplesmente refletir a informação de apenas um dos projetos dentro do programa, elas ainda devem ser compartilhadas com cada um dos membros das outras equipes do projeto.

Embora seja possível que muitas pessoas irão ignorar as comunicações que elas não acreditam serem relevantes para o que foram designadas a fazer, mais comunicação versus menos, acabará por reduzir falhas de comunicação no final.

Finalmente, ao passo que para a maioria das informações relacionadas ao projeto cada equipe assumirá a sua própria responsabilidade de se comunicar dentro da equipe, os padrões para as comunicações ainda devem ser aplicados. Por exemplo, todas as reuniões de equipe deverão ter agendamentos publicados, reuniões publicadas e lista de afazeres.

A lista de participantes reais versus planejados deve ser incluída. As reuniões devem ser publicadas em um site compartilhado do programa com a intenção de permitir que qualquer membro do programa possa participar como “ouvinte”.

É fundamental aqui que participantes não relacionados ao projeto compreendam o seu papel como ouvintes, a fim de tornar as reuniões mais eficientes e não se atolar em questões não relacionadas.

Por último, relatórios periódicos (semanal, quinzenal) devem ser publicados por cada equipe de projeto utilizando um formato consistente e consolidado pela equipe do programa para ampla distribuição. Isso permite que os membros da equipe se ajustem rapidamente ao desenvolvimento do programa sem ter de esperar reuniões ou ler outros resultados.

Gerenciamento dos Riscos: Desafios e Soluções

Os riscos do programa podem ter impactos em todo o programa, incluindo a programação, qualidade de entregas, considerações de design, testes e outras áreas.

Riscos do cronograma normalmente começam durante o planejamento do projeto.  Em muitos casos, os projetos dentro de programas, geralmente, têm cronogramas de início e término diferentes.

Isso, frequentemente, é feito para reduzir o risco de um “big bang”, para distribuir os recursos de uma forma mais uniforme, estender o orçamento do programa por um período de tempo mais longo e simplesmente para considerar a duração real dos projetos de forma individual.

Enquanto essa abordagem faz sentido no geral, existem riscos associados a ela que precisam ser cuidadosamente gerenciados.

Um dos riscos significativos associados com essa abordagem é a integração de características cruzadas ou de plano de projetos cruzados.

Em uma implementação de sistema, por exemplo, os projetos separados, cada um com produtos separados, estão, muitas vezes, destinados a serem integrados em algum grau.

Por exemplo, um sistema de serviço ao cliente pode integrar uma informação de faturamento em um sistema financeiro separado e não integrado.  Decisões tomadas dentro de um de um plano projeto podem ter um impacto significativo no plano de outro projeto.

Além disso, se dois projetos trabalham a partir de cronogramas diferentes, e mais significativamente, se um projeto finaliza antes do outro começar, então existe um risco potencial.

Apesar de equipes de projetos separadas dentro de um programa terem de comunicar seus status entre si através de relatórios do programa ou reuniões do programa, esta forma de comunicação nem sempre atenua os riscos de impacto sobre o plano devido à falta de participação das equipes em nível de detalhamento.

Outro risco está relacionado com testes de integração. Um teste totalmente completo de integração de sistemas para todos os projetos, em um cenário como o do exemplo acima, é necessário para assegurar que todos os componentes trabalhem em conjunto.

Enquanto eventos de testes de projetos separados são obrigatórios, os programas normalmente limitam a integração cruzada de projetos às “interfaces”.

Como citado acima, quando diferentes projetos têm diferentes datas de início, é, frequentemente, impossível conduzir o teste de integração cruzada de projeto.

Enquanto o teste de regressão é, certamente, uma opção a ser usada para atenuar tal risco, é, normalmente, muito tarde para fazer mudanças de plano dentro do programa, se as datas de início já tiverem passado para o primeiro projeto e se o teste de regressão mostrou um erro significante ou mudança de plano.

Os programas, normalmente, tentam resolver esse risco agendando a finalização simultânea de todos os projetos, mesmo que ainda existam inícios escalonados.

O impacto aqui, contudo, é que um deslize em qualquer um dos vários projetos terá um impacto na entrega de todos os outros projetos dentro do programa.

Isso gera, desnecessariamente, custos e cronograma excedentes de tempo dos projetos pontuais.

Riscos integrados de planos

Soluções que falam sobre os riscos integrados de planos são tipicamente ignorados nos programas reais, simplesmente porque existe uma percepção de que qualquer alternativa para o início e o término normais de um projeto custa mais e leva mais tempo.

As equipes normalmente empregam um especialista no assunto de cruzamento de projetos como os “olhos e ouvidos” para o programa.

Contudo, em termos de atenuação de riscos, uma abordagem menos comum pode ser realmente mais barata a longo prazo, e proporcionar uma validação de resultados mais completa.

Uma maneira eficaz de planejar programas para redução de riscos de planos é usar a abordagem de “único início-continuação múltipla”. No início do programa, todas as equipes de projetos iniciam ao mesmo tempo.

Elas conduzem sessões de análises e planos, processos de validação As-Is, requisitos técnicos e funcionais e visões to-be, simultaneamente.

As entregas à partir desse ponto inicial tornam-se, então, entradas dentro de um programa único de comparação de fases cruzadas de projetos (Phase-cross-project).

Isso implica num processo formal que compara os resultados de cada projeto e observa especialmente o plano ou as situações construídas que podem impactar negativamente cada projeto.

As equipes de programa, então, avançam para resolver as expectativas e consentir na abordagem final para a integração.

Essa fase única não é limitada para o sistema ou plano do processo. Ela também pode ser aplicada em outros processos com projetos tais como:

• Treinamentos;
• Controles pós início;
• Comunicações;
• Licenciamento,
• Contratação;
• E outros componentes.

O aceite das conclusões dessa fase torna se, então, o ponto inicial para que todos os projetos prossigam.

Nesta conjuntura, não é necessário que todas as equipes de projeto evoluam juntas. Um novo plano de início-término pode ser aplicado com risco e repetição de trabalho reduzidos.

Teste integrado do programa

Enquanto a abordagem de único início-continuação múltipla funciona bem para reduzir riscos iniciais cruzados de planos de projetos, esse teste integrado não pode ser aplicado posteriormente de forma fácil, em um programa, se os projetos separados já tiverem sido iniciados mas terminarão em tempos diferentes.

Isso, depois, se transforma num risco significativo para a qualidade e repetição de trabalho. Ele se torna especialmente difícil quando as datas de término de alguns projetos forem próximas uma das outras.

A ocasião para o teste integrado irá, em ultima análise, impactar o cronograma e o custo de uma equipe.

A única estratégia para eliminar esse risco é inspecionar cada projeto como se fosse um novo lançamento e efetuar um sistema excepcional, testes de regressão e execução como parte dos objetivos da segunda equipe.

Isso provavelmente eliminará um benefício do programa, mas a longo prazo, criará um resultado de melhor qualidade.

Conclusão

Em conclusão, o gerenciamento de programas é uma maneira sólida e benéfica para as organizações gerenciarem grupos de projetos.

Quando consistentes e integrados, os processos são aplicados para cada um dos projetos dentro de um programa, os riscos podem ser reduzidos e a qualidade melhorada, o que contribui para os objetivos gerais da iniciativa.

Os controles de amostras evidenciadas no presente artigo são o início de qualquer consideração do gerenciamento de programas, e quando aplicados a características de outros programas, podem ser considerados um sucesso para todos.

Referências

• https://brasil.pmi.org/brazil/KnowledgeCenter/Articles/~/media/25F7892986EA4C6C86B81493D7F1A