Diferenciando Programas de Projetos

Por Clay Susini Aquino Junior, PMP

Um equívoco comum cometido pelos Escritórios de Gerenciamento de Projetos é conceber um Programa como Projeto ou vice e versa.

Em um primeiro momento esse tema parece soar sem importância, como se fosse apenas mais uma definição teórica e puramente conceitual, mas é a base para o fracasso real de inúmeros Projetos.

No Brasil e, principalmente, no setor corporativo privado, Projetos são erroneamente definidos como Programas apenas por serem grandes. Mas o tamanho é simplesmente a consequência, e não o motivo para um Programa existir.

Outras justificativas usadas para transformar conjuntos de Projetos em Programa são o aproveitamento da dinâmica comum de vários recursos e a existência de inúmeras frentes de trabalho com mais de um time. Realmente Programas possuem essas características, mas apenas como consequência de um fator maior: a concepção de uma idéia geradora de um benefício estratégico, dando origem a um conjunto de iniciativas independentes responsáveis por concretizar o benefício idealizado.

Um Programa, antes de se tornar um conjunto de projetos, nasce como uma idéia estratégica geradora de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco ou dezenas de Projetos independentes. No momento de concepção do Programa, não sabemos ao certo o que deve ser feito para atingir o benefício idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas independentes gerará um benefício estratégico e único. E é comum um Programa, em plena execução, ainda gerar novos Projetos com o intuito de consolidar o benefício estratégico definido anteriormente.

Por sua vez, Projeto é um esforço pontual, menos abstrato. Por mais que um Projeto em sua fase de iniciação possua indefinição de escopo, tempo e custo, sempre temos em mente a principal entrega. Sabemos o “o que”. Apenas não sabemos ainda o “como”. E nesse contexto, para diferenciar um Projeto de um Programa, não importa o tempo, o custo e nem a quantidade ou interação entre os recursos.

Parafraseando o PMBoK (Project Management Body of Knowledge), do PMI (Project Management Institute), Projeto é um empreendimento temporário, com recursos limitados, que gera um resultado, produto ou serviço único. Já Programa é um conjunto de Projetos independentes que estão unidos e associados estrategicamente para geração de um benefício. Em um Programa, obviamente cada projeto possui um benefício próprio, afinal são independentes. Mas o benefício gerado pelo Programa é diferente dos benefícios individuais de cada Projeto. E esse benefício do Programa é geralmente pensado primeiramente e estrategicamente antes de ser criado o conjunto de Projetos.

Como exemplo, podemos citar o Programa de Aceleração do Crescimento (PAC) do Governo Federal. O Programa possui como objetivo construir infraestrutura logística e energética para sustentar o crescimento do País. O objetivo de um Programa sempre terá a característica de ser abstrato, pois na concepção da idéia só há a expectativa do benefício e não do objeto entrega. Não sabemos exatamente o que terá que ser feito para que o benefício seja obtido, tampouco como.

O Governo Federal dividiu o PAC em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.

Cada um desses Subprogramas possui vários Projetos. Por exemplo, o Subprograma Cidade Melhor possui o Projeto Construção Estação de Tratamento de Esgoto na Baixada Santista, o Projeto de Construção de Drenagem Urbana na Baixada Fluminense, entre outros. E há também os Projetos internos do Programa que não são expostos à população, como Projetos de marketing para promover o Programa em rádio, TV e Internet, Projetos de Desenvolvimento de Sistemas de Informação do Governo etc.

Outra característica dos Programas é a existência das Frentes de Trabalho. Em tradução livre do The Standard for Program Management do PMI, Programas incluem elementos de trabalho não contidos em nenhum de seus Projetos. Esses elementos são as Frentes de Trabalho, que atravessam os Projetos, não necessariamente todos, apoiando a integração necessária para o benefício único do Programa. Como exemplo, a auditoria interna poderia ser uma Frente de Trabalho do PAC. As ações de auditoria atravessariam os Projetos gerando o benefício de integridade do Programa como um todo. Mas oficialmente o PAC possui duas Frentes de Trabalho: Medidas Institucionais e econômicas e a outra é Desenvolvimento Econômico Social.

A construção de uma usina hidrelétrica, por exemplo, se idealizada unitariamente, é um Projeto. Mesmo que demore 10 anos para ser construída e mobilize bilhões de reais, continuaria sendo um Projeto, e não um Programa, pois o que foi idealizado é o produto de forma direta.

Essa usina poderia estar dentro do Programa de Aceleração do Crescimento, e seria completamente normal caso a usina não tivesse sido idealizada no momento da concepção do Programa, pois se pensou no benefício da Aceleração do Crescimento no Brasil, e não em todas as entregas palpáveis que concretizariam esse benefício.

Programas geralmente possuem fases futuras totalmente abstratas em escopo, tempo e custo, muito mais abstratas que as fases futuras de um Projeto. De maneira rotineira, Programas são subdivididos em fases ou subprogramas. A primeira fase constantemente possui projetos visualizados com mais clareza ou já em execução. E a as demais com a visualização apenas da percepção do benefício desejado.

Após toda essa exposição conceitual, ainda perdura a dúvida: qual o problema em confundir Projeto com Programa ou vice e versa?

Conceber e executar um Projeto como Programa não é tão grave, mas certamente criará na corporação uma imagem errada do que é Programa e a sensação de que gerenciar Programa é o mesmo que gerenciar Projeto. E caso a corporação comece a implementar o conceito de Programa, terá dificuldade em difundir o conceito correto.

Porém, será catastrófico executar um Projeto quando na verdade for um Programa. O “Projeto” sofrerá aumento de escopo e prazo constantemente e a corporação não entenderá o motivo, mas ocorre que o peso de uma idéia estratégica, que é abstrata, foi delineado para ser entregue em um único “Projeto”, que possui um molde pontual e bem mais objetivo que a fase inicial de um Programa. O titulado “Projeto” nesse caso, terá inúmeras fases e mais cedo ou mais tarde essas serão tão independentes uma das outras que possuirão entregas totalmente diferentes, autossuficientes e com objetivos próprios. Novas entregas começarão a ser criadas no decorrer do ciclo de vida e não serão bem aceitos pela corporação, pois serão concebidas como se fossem incrementos de escopo (scope creep) e causadoras de atraso, quando na verdade são novos Projetos, independentes, e que apenas agora se visualizou a necessidade estratégica de criá-los e assim solidificar cada vez mais a expectativa abstrata inicial. Essa sucessão de desastres costuma ocorrer quando se faz a gestão de um Projeto sendo na verdade um Programa.

Texto publicado na e-News do PMI São Paulo de dezembro de 2011

Sobre o autor: Clay Susini Aquino Junior é Gerente de Programas e Projetos da BM&FBOVESPA, certificado Project Management Professional (PMP), MBA em Gerenciamento de Projetos pela Fundação Getúlio Vargas, Bacharel em Sistemas de Informação com Ênfase em Planejamento Estratégico pela Universidade Presbiteriana Mackenzie, membro do PMI (Project Management Institute) e do IFPUG (International Function Point Users Group).