quinta-feira, 3 de outubro de 2013

Diferença entre PROCESSOS X PROJETOS (projetos versus processos)

7 PROCESSOS

Diversas são as definições para a palavra processo. Sua origem está relacionada ao latim “procedere”, de “pro” (à frente) mais “cedere” (ir), ou seja, em sua etimologia, o termo processo pode ser entendido como um conjunto de passos para avançarmos ao encontro a um objetivo pré-estabelecido.

Segundo o guia BPM CBOK^®(2009)[2], “processo é um conjunto definido de atividades ou comportamentos executados por humanos ou máquinas para alcançar uma ou mais metas [...] são compostos por várias tarefas ou atividades inter-relacionadas que solucionam uma questão específica”. Além disso, o guia afirma que “os processos são disparados por eventos específicos e apresentam um ou mais resultados que podem conduzir ao término do processo ou a transferência do controle para outro processo”.

No âmbito do Governo Federal, considerando os conceitos e as diretrizes do Programa Nacional de Gestão Pública e Desburocratização (GesPública)[3], encontramos definições que traduzem processo como “um conjunto de decisões que transformam insumos em valores gerados ao cliente/cidadão”, ou ainda, “um conjunto de recursos e atividades inter-relacionadas ou interativas que transformam insumos (entradas) em serviços/produtos (saídas)”.

Observa-se, de modo geral, que os conceitos disponíveis apontam para o entendimento de que um processo transforma INSUMOS em PRODUTOS ou SERVIÇOS, utilizando RECURSOS disponíveis, seguindo condições estabelecidas pela REGULAMENTAÇÃO, por meio de um conjunto pré-estabelecido e sequencial de ATIVIDADES.

Processo pode ser definido como um conjunto de atividades ou comportamentos internos rotineiros, executados por humanos ou máquinas para alcançar uma ou mais metas e compostos por várias atividades inter-relacionadas que solucionam uma questão específica transformando insumos em produtos ou serviços.

Processo, então, é a forma como a partir de um ou mais INSUMOS (o que precisamos), agregamos valor através da execução de ATIVIDADES (o que fazemos) realizadas nas organizações e suas unidades, entregamos um RESULTADO (o que entregamos). O processo é suportado por RECURSOS (aonde fazemos, o que e quem utilizamos), que podem ser humanos, sistemas de informação, equipamentos, edificações, entre outros, e orientado pela REGULAMENTAÇÃO (porque, quando e como fazer), a exemplo de políticas, mecanismos de controle, legislações, regras de negócio. A figura abaixo representa o processo e seus elementos.

Figura 9- Elementos de um processo.

Tomemos como exemplo o processo genérico de compras. No serviço público, a partir das necessidades apresentadas pelos agentes públicos, formalizadas na forma de especificações técnicas (INSUMOS), são executadas diversas ações (ATIVIDADES) para a aquisição dos materiais e/ou serviços demandados (PRODUTOS). Além disso, a execução do processo é norteada por uma série de normas internas e externas, em especial a lei nº 8.666/93 (REGULAMENTAÇÃO), sendo, ainda, requeridos sistemas, pessoal e equipamentos (RECURSOS) para realização do processo.

No entanto é importante ressaltar que quando falamos de processo não estamos falando das unidades organizacionais, nem das atribuições específicas da área de responsável em um processo de compras, como citado anteriormente. Estamos falando de como funciona o processo, o que inclui atividades realizadas por diversas áreas para transformar insumos em produtos e serviços.

Um processo não é limitado a uma área funcional e isso fica mais evidente quando nos deparamos com um problema na aquisição de insumos realizada em um processo de compras, por exemplo. A origem do problema poderá estar em diversas áreas. Seja no demandante, que não consegue especificar de forma adequada as suas necessidades de compra; seja na área de licitações, a qual não elabora adequadamente o edital; seja, ainda, no almoxarifado, que não controla adequadamente o estoque, levando à execução de compras desnecessárias.

Quando queremos resolver problemas na aquisição de bens e serviços não adianta, por exemplo, apenas focar dentro da área funcional de compras. É necessário construir uma visão integral do processo, que denominamos de visão ponta-a-ponta, e entender como as decisões são tomadas ao longo do tempo, e aí sim propor melhorias com base nessa visão do todo.

Como exemplo, consideremos a emissão da carteira de identidade civil (RG), que é o resultado de um processo cujo objetivo final é atender a um cliente externo: o cidadão.

Cabe ressaltar que, até chegar ao cidadão, são executadas, em uma sequência temporal e pré-determinada, diversas atividades, como atendimento ao público, conferência de documentação, confecção do RG, envio do RG à unidade solicitante, recebimento do RG e sua entrega final ao cidadão. Nesse processo, os colaboradores da organização se relacionam com usuários internos e externos, fornecendo e/ou recebendo insumos e consumindo recursos em busca de um objetivo comum: a entrega do passaporte ao cidadão.

Com base no exemplo citado, nota-se, com clareza, a diferença entre processos (rotineiros) e projetos (temporários e voltados a resultados exclusivos). Como forma de reforçar a relação e a diferenciação entre os conceitos de projeto e processo, cabe destacar que um projeto pode ter como objetivo a criação ou o aprimoramento de um processo.

[2] O BPM CBOK® é um corpo comum de conhecimentos sobre BPM (Gestão de Processos de Negócio) e foi projetado pela Association of Business Process Management Professionals (ABPMP) para auxiliar profissionais de Gestão de Processos, fornecendo uma visão abrangente das questões, melhores práticas e lições aprendidas sobre o tema. Para saber mais acesse: http://www.abpmp-br.org/

[3] O Programa Nacional de Gestão Pública e Desburocratização (GesPública) é o resultado da evolução histórica de uma série de iniciativas do Governo Federal para promover a gestão pública de excelência. Criado em 2005 por meio do Decreto 5.378 de 23 de fevereiro de 2005, o Programa tem como principais características: ser essencialmente público, ser contemporâneo, estar voltado para a disposição de resultados para a sociedade e ser federativo. Mais em http://www.gespublica.gov.br/

----------------------------------------------------------------------------------------------------------

7.1 DIFERENÇAS ENTRE PROJETO E PROCESSO

Vimos que as definições de projeto e processo são:

Projeto – Projeto é um esforço planejado, com início e fim definidos, caracterizado por criar algo novo, único ou singular, que não havia sido feito antes da mesma maneira. É feito por pessoas e sofre restrições, principalmente de tempo e custo e pode ser planejado de forma progressiva.

Processo – Processo é um conjunto definido de atividades ou comportamentos internos rotineiros, executados por humanos ou máquinas para alcançar uma ou mais metas e compostos por várias atividades inter-relacionadas que solucionam uma questão específica transformando insumos em produtos ou serviços.

Entre os conceitos de projeto e processo apresentados, a maior diferença está no fato de que um projeto é feito para acabar quando seu objetivo é atingido, enquanto que um processo é feito para ser perpetuado e atingir resultados cada vez mais padronizados e eficientes.

Para o PMBOK^® (2008), “os projetos e as operações (processos) diferem principalmente no fato de que as operações (processos) são contínuas e produzem produtos, serviços ou resultados repetitivos... o trabalho de operações é contínuo e mantém a organização ao longo do tempo”. Dessa forma as operações (processos) sustentam o trabalho e o esforço dos projetos.

Apesar disso, projeto e processo possuem como ponto em comum a busca da melhoria contínua. Projeto através de um esforço temporário, processo através da melhoria contínua de ações seqüenciais para se atingir um determinado resultado. Também ambos procuram obter a perpetuação deste resultado.

Mesmo não se confundindo com processos, os quais se repetem periodicamente desenvolvendo resultados similares a cada novo ciclo, a condução de um projeto também faz uso de várias atividades repetitivas. Para que se possa trilhar o ciclo de vida do projeto, executando cada vez melhor as atividades de iniciação, planejamento, execução, monitoramento e controle e encerramento das fases de um projeto, executam-se processos pré-definidos, agrupados em grupos de processos, para se atingir os objetivos propostos.

Vejamos as diferenças básicas entre projeto e processo:

PROJETO	PROCESSO
· Esforço temporário e único; · Tem início e término definidos; · A equipe, reunida para este fim, planeja e executa o projeto; · Enfrenta riscos e escopos que podem ser desconhecidos; · Utiliza equipe multidisciplinar em sua execução; · Termina com a criação de produto, serviço ou resultado exclusivo. · A produtividade pode variar e a qualidade dos resultados deve ser medida constantemente; · A sua execução pode exigir contingenciamentos e mudanças constantes.	· Atividade contínua; · Repete-se periodicamente; · As mesmas pessoas ou máquinas desempenham as mesmas tarefas a cada novo ciclo do processo; · Os riscos são conhecidos e controlados e o ambiente é estável; · A equipe pode ser individual e monodisciplinar; · Voltado à execução de um produto ou serviço conhecido e parametrizado; · Controle de produtividade é estabelecido em torno de padrões e metas de produção; · Constituído por uma sequência coerente de atividades e desvios conhecidos.

--------------------------------------------------------------------------------------------------

REFERÊNCIAS

BRASIL. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Planejamento e Investimentos Estratégicos. Manual de Elaboração: plano plurianual 2008-2011/ Ministério do Planejamento, Orçamento e Gestão. Secretaria de Planejamento e Investimentos Estratégicos. Brasília: MP, 2007.

PMI. Project Management Institute. Project Management Body of Knowledge - PMBOK, 4. ed., 2008.

ABPMP. Association of Business Process Management Professionals. Guia para Gerenciamento de Processos de Negócio Corpo Comum de Conhecimento - BPM CBOK, v. 2.0, 2009.

Brasil. Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Metodologia de Gerenciamento de Projetos do SISP / Ministério do Planejamento, Orçamento e Gestão, Secretaria de Logística e Tecnologia da Informação. - Brasília: MP, 2011.

BPM CBOK - ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). Guia para Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento - Versão 2.0, 2009.

PRADO, Darci Santos do. Planejamento e Controle de Projetos. Série Gerência de Projetos. Nova Lima (MG), INDG, 2004.

Material preliminar do PMBOK® 5ª Edição - 2013 colhidos no website da Revista Mundo Project e no website do consultor Ricardo Vargas;

O que é projeto, subprojeto, programa e portfólio de projetos

3 PROJETO

Para o PMBOK^® (2008), “projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”.

De acordo com a Metodologia de Gerenciamento de Projetos do Sistema de Administração dos Recursos de Tecnologia da Informação (MGP-SISP) [1] do Ministério do Planejamento, Orçamento e Gestão (MPOG) do Brasil, “projeto é um empreendimento planejado, orientado a resultados, possuindo atividades com início e término, para atingir um objetivo claro e definido. Os projetos são empreendidos em todos os níveis organizacionais podendo envolver uma ou múltiplas unidades”.

Tanto na definição apresentada pelo PMBOK^®(2008), quanto na acepção do Ministério do Planejamento, o conceito de projeto considera a existência de um esforço predefinido relacionado a um produto ou serviço a ser entregue. Os projetos podem ser classificados quanto ao tamanho, complexidade e grau de sua incerteza.

Cabe destacar que a natureza temporária de um projeto não está, necessariamente, relacionada ao fato de ter curta duração, mas, à existência de um início e um fim definidos e associados ao alcance dos objetivos do projeto. Além disso, o termo temporário não se refere ao produto, serviço ou resultado criado pelo projeto, pois a maioria dos projetos tem o objetivo de criar um resultado duradouro.

Conclui-se, então, que projeto pode ser definido como um esforço planejado, com início e fim definidos, em função de um problema, oportunidade ou interesse, caracterizado por criar algo novo, único ou singular, sendo feito por pessoas e sofrendo restrições, principalmente de tempo e custo e podendo ser planejado de forma progressiva. O esforço singular e planejado de um projeto não se confunde com as atividades rotineiras da organização, as quais se repetem periodicamente desenvolvendo resultados similares a cada novo ciclo.

O término de um projeto está associado à efetivação das entregas (produtos ou serviços) que foram previstas em seu planejamento (objetivos e escopo) ou quando se concluir que tais objetivos não poderão ser alcançados por algum motivo ou ainda, quando os interessados no projeto concluírem que o mesmo não é mais necessário.

Um projeto possui elementos com as seguintes características:

· Objetivos determinados – alinhamento estratégico (O quê?);

· Abrangência definida – escopo (Como?);

· Prazo delimitado – prazo (Em quanto tempo?);

· Recursos específicos – custos (Quanto vai custar?); e

· Responsabilidade de execução definida – partes interessadas (Quem?);

· Riscos identificados – riscos (O que pode dar errado?).

Objetivos determinados – alinhamento estratégico (O quê?): Esta característica se relaciona com o atendimento das necessidades do negócio da organização. Uma necessidade pode ser baseada em uma demanda de mercado, mutação organizacional, avanço tecnológico ou marco legal. O objetivo do projeto deve estar alinhado ao planejamento estratégico da organização, deve ser passível de mensuração e conter critérios de sucesso relacionados.

Abrangência definida – escopo (Como?): Esta característica se relaciona com os passos necessários para que os objetivos do projeto sejam atingidos. O escopo é composto da relação das entregas a serem realizadas, do trabalho necessário para atendimento dos objetivos e do nível de qualidade exigido de tais entregas. O escopo também inclui explicitamente o que não será feito no projeto para nivelamento das expectativas dos interessados e orientação de alto nível da equipe do projeto.

Prazo delimitado – prazo (Em quanto tempo?): Esta característica se relaciona com o tempo necessário para consecução do trabalho envolvido em cada entrega e no projeto como um todo. Seu resultado é o cronograma do projeto. Entretanto, para se chegar ao cronograma, é necessária a prévia definição das atividades envolvidas em cada entrega, o seqüenciamento, ordenamento e quantificação temporal dessas atividades. Por fim, alinhado ao cronograma, temos também a relação dos recursos necessários para consecução de suas atividades.

Recursos específicos – custos (Quanto vai custar?): Esta característica se relaciona com as estimativas e o próprio gerenciamento dos custos envolvidos para efetivação de cada entrega e do projeto como um todo. Os custos do projeto podem ser influenciados pelas variações e interesses do mercado, política governamental, fatores de risco inerentes ao projeto e pelo próprio tempo de duração do projeto (“Tempo é dinheiro!”). Seu resultado são as avaliações quantitativas dos prováveis custos vinculados a cada entrega, os orçamentos mais realistas possíveis e as medidas efetivas rotineiras de controle do orçamento para evitar a extrapolação dos valores planejados.

Responsabilidades de execução definidas – partes interessadas (Quem?): Esta característica se relaciona com a organização e gerenciamento da equipe do projeto e das demais partes interessadas, onde são definidos papéis e responsabilidades na execução das entregas e coordenação dos trabalhos de forma integrada. Também pode envolver ações necessárias à mobilização e desenvolvimento da equipe do projeto, como recrutamentos e capacitações, bem como gerenciar o desempenho e conflitos do trabalho dos membros envolvidos no projeto.

Riscos identificados – riscos (O que pode dar errado?): Esta característica se relaciona com a identificação e monitoramento, de forma contínua, das ameaças e das oportunidades que podem impactar os objetivos e resultados do projeto (riscos). Envolve também a criação de estratégias e respostas que aumentem a probabilidade e o impacto dos eventos positivos e diminuam a probabilidade e o impacto dos eventos negativos que influenciam os resultados de um projeto. Os riscos são inerentes à natureza de um projeto, derivando das incertezas do ambiente do projeto e de seus próprios requisitos.

3.1 Subprojeto

Subprojeto é a parte menor de um projeto criada quando há a necessidade da subdivisão do esforço planejado em componentes mais facilmente gerenciáveis.

Um projeto, dependendo do tamanho e quantidade de entregas e atividades, pode tornar-se difícil de gerenciar. Um projeto de construção de um edifício, por exemplo, exigirá diversas entregas relativas à concepção arquitetônica, cálculo de estruturas, orçamentos de materiais e serviços, contratação da construtora, acompanhamento da execução e qualidade, cronograma de execução física e financeira, obtenção de licenças públicas e ambientais, marketing de vendas, etc. O controle centralizado, na forma de um único cronograma, com centenas de atividades pode facilmente sair do controle.

A divisão das atividades de um projeto em subprojetos permite a delegação de responsabilidades e possibilidade de vários gerentes atuarem de forma integrada. Dessa forma, o sucesso de determinado projeto está relacionado ao alcance dos objetivos dos subprojetos a ele vinculados.

Em termos de gerenciamento de projetos dividir um projeto em subprojetos distribui responsabilidades àqueles que efetivamente realizam o trabalho ou podem supervisioná-lo de forma mais direta, além de combinar a autoridade do gerente com prestação de contas em tempo real. A criação de subprojetos dentro de um projeto principal ajuda os gerentes de projetos a obter acesso às partes do cronograma e a ter controle sobre essas partes.

A eficiência e eficácia da atuação dos gerentes em subprojetos pode ser alavancada se tais gerentes puderem: saber como o trabalho de suas equipes impacta no projeto principal, planejar o trabalho de suas equipes e ser responsáveis diretos por entregas e atividades. Ou seja, informação, descentralização e responsabilização como aspectos de sucesso no trabalho com subprojetos.

Aspectos que devem ser considerados na decisão de decompor um projeto em subprojetos[2]:

Tamanho do projeto: Se o projeto contiver mais de algumas centenas de tarefas, decompô-lo em subprojetos poderá facilitar o gerenciamento. Se algumas partes do projeto incluírem um trabalho fragmentado em mais detalhes do que as demais, talvez faça sentido transformar essas partes em subprojetos, para que a maioria dos usuários veja somente uma descrição geral do subprojeto, mas para que os interessados possam ver o conteúdo com mais detalhes. Um único projeto quase sempre é a alternativa mais rápida, embora a capacidade de gerenciar cronograma, comunicações, riscos e contramedidas, expectativas das partes interessadas e aceites das entregas possa ser diminuída com a atuação de um único gerente.
Nível de descentralização da organização: Em um ambiente descentralizado ou distribuído, ter um projeto dividido em subprojetos pode proporcionar aos funcionários maior controle sobre os seus próprios trabalhos do que um único arquivo de projeto centralizado.
Nível de eficiência dos métodos de planejamento da organização: Se pessoas (gerentes em potencial) atuando em diferentes níveis na organização forem responsáveis por atividades específicas e souberem quais delas são necessárias no projeto, pode ser mais sensato permitir que eles planejem e executem o trabalho de suas equipes em subprojetos e consolidem seus cronogramas em um projeto principal. Se o planejamento "de cima para baixo" for a norma da organização, convém reorganizar o projeto inicial em subprojetos quando ele for implementado, de forma que equipes ou gerentes de projeto individuais tenham acesso aos seus próprios cronogramas e possam controlá-los, de forma compartimentada.
Hierarquia entre projetos: Alguns projetos podem estar subordinados ou relacionados a outros projetos. Desta forma, alguns projetos podem vincular-se a outros como subprojetos daqueles. A precisão desta hierarquia ou relação pode resultar em uma estrutura de projetos e subprojetos, que deve refletir as prioridades e as responsabilidades de cada área da organização, bem como os inter-relacionamentos entre atividades em diferentes áreas e o alcance temporal dos projetos.
Necessidade de várias pessoas modificarem um projeto: Os dados de um projeto devem ser administrados e modificados por um único gerente de projeto ou seu adjunto. No entanto, muitas vezes um projeto engloba um cronograma muito extenso, em que pessoas em diferentes níveis na organização necessitam acessar, gravar ou alterar as informações do projeto. A divisão do projeto principal em subprojetos proporciona a organização do acesso de forma compartimentada e independente, proporcionando segregação no acesso e alteração das informações globais do projeto principal. Os membros das equipes dos subprojetos podem concentrar o foco no seu trabalho, visualizando apenas os dados referentes às suas atividades, enquanto o gerente do projeto principal pode coordenar o cronograma de cada equipe de subprojeto e o cronograma principal.

[1] A Metodologia de Gerenciamento de Projetos do SISP(MGP-SISP) é um conjunto de boas práticas em gerenciamento de projetos para os órgãos da administração pública. O SISP é o Sistema de Administração dos Recursos de Tecnologia da Informação, conforme decreto 7.579 de 11 de outubro de 2011. A Secretaria de Logística e Tecnologia da Informação (SLTI) do Ministério do Planejamento, Orçamento e Gestão (MP) do Brasil, é o órgão central deste sistema. Para saber mais, acesse: http://www.planejamento.gov.br/ministerio.asp?index=7

planos-dentro-de-planos-projetos-mestres-e-subprojetos-HA001226035.aspx

----------------------------------------------------------------------------------------------------

4 PROGRAMA

Segundo o PMBOK^® (PMI, 2008), programa é um grupo de projetos relacionados e gerenciados de modo coordenado para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados individualmente.

No entanto, para o Ministério do Planejamento, Orçamento e Gestão (MP), Programa “é o instrumento que articula um conjunto de ações (orçamentárias e não orçamentárias) suficientes para enfrentar um problema, devendo seu desempenho ser passível de aferição por indicadores coerentes com o objetivo estabelecido.” (BRASIL, 2007, p.41). Para a MGP-PF os dois conceitos se complementam.

Segundo o PMBOK^®(2008), “os gerentes de programas são responsáveis pelo gerenciamento de projetos relacionados de forma coordenada visando obter benefícios e controle não disponíveis quando gerenciados individualmente. Os gerentes de programas interagem com cada gerente de projetos para oferecer apoio e orientação em projetos individuais.”

5 PORTFÓLIO

Um portfólio refere-se a “um conjunto de projetos ou programas e outros trabalhos agrupados para facilitar o gerenciamento eficaz desse trabalho a fim de atingir os objetivos estratégicos de negócios”. (PMBOK^®, 2008, p.439).

“Os projetos ou programas do portfólio podem não ser necessariamente interdependentes ou diretamente relacionados. Por exemplo, uma empresa de infraestrutura que tenha o objetivo estratégico de “maximizar o retorno sobre os seus investimentos” pode compor um portfólio que inclua uma mescla de projetos em petróleo e gás, energia, água, estradas, ferrovias e aeroportos. A partir dessa mescla, a empresa pode escolher gerenciar projetos relacionados como um programa. Todos os projetos de energia podem ser agrupados como um programa de energia. Da mesma forma, todos os projetos de água podem ser agrupados como um programa de água” (PMBOK^®, 2008, p.08).

Figura 7- Imagem ilustrativa de portfólio de projetos, programas e outras ações

O gerente de portfólio é responsável pela governança de alto nível de um conjunto de projetos ou programas, que podem ou não ser independentes. Através de comitês ou individualmente, os gerentes de portfólio analisam e priorizam cada projeto de acordo com o investimento e recursos necessários, riscos associados, aderência ao planejamento estratégico, cenários prospectivos internos e externos e norteamento político da organização.

Esta priorização pode ser realizada anualmente, de forma a nortear e coincidir a busca por recursos com o ciclo anual do orçamento público e com o plano plurianual.

Na tabela abaixo, podemos verificar os níveis de atuação, em aspectos específicos, dos projetos, programas e portfólio.

Tabela 3- Resumo comparativo entre o gerenciamento de projetos, programas e portfólio. PMBOK^® (2008)

ASPECTO	PROJETOS	PROGRAMAS	PORTFÓLIO
Escopo	Projetos possuem objetivos definidos. O escopo é elaborado progressivamente durante o ciclo de vida do projeto.	Os programas possuem um escopo maior e fornecem benefícios mais significativos.	Os portfólios possuem um escopo de negócios que muda com os objetivos estratégicos da organização.
Mudança	Os gerentes de projetos esperam mudanças e implementam processos para mantê-las gerenciadas e controladas.	Os gerentes de programas devem esperar mudanças tanto de dentro como de fora do programa e estar preparados para gerenciá-las	Os gerentes de portfólios monitoram continuamente as mudanças ocorridas no ambiente mais amplo da organização.
Planejamento	Os gerentes de projetos elaboram progressivamente planos detalhados no decorrer do ciclo de vida do projeto a partir de informações de alto nível.	Os gerentes de programas desenvolvem o plano geral do programa e criam planos de alto nível para orientar o planejamento detalhado no nível dos componentes.	Os gerentes de portfólios criam e mantêm comunicação e processos necessários ao portfólio global.
Gerenciamento	Os gerentes de projetos gerenciam a equipe do projeto para atender aos objetivos do projeto.	Os gerentes de programas gerenciam a equipe do programa e os gerentes de projetos; eles provêem visão e liderança global.	Os gerentes de portfólios podem gerenciar ou coordenar a equipe de gerenciamento de portfólios.
Sucesso	O sucesso é medido pela qualidade do produto e do projeto, pontualidade, conformidade orçamentária e grau de satisfação do cliente.	O sucesso é medido pelo grau em que o programa atende às necessidades e aos benefícios para os quais foi executado.	O sucesso é medido em termos do desempenho agregado dos componentes do portfólio.
Monitoramento	Os gerentes de projetos monitoram e controlam o trabalho de elaboração dos produtos, serviços ou resultados para as quais o projeto foi realizado.	Os gerentes de programas monitoram o progresso dos componentes do programa para garantir que os objetivos, cronogramas, orçamento e benefícios globais do mesmo sejam atendidos.	Os gerentes de portfólios monitoram o desempenho e os indicadores de valor agregado da carteira.

REFERÊNCIAS

PMI. Project Management Institute. Project Management Body of Knowledge - PMBOK, 4. ed., 2008.

ABPMP. Association of Business Process Management Professionals. Guia para Gerenciamento de Processos de Negócio Corpo Comum de Conhecimento - BPM CBOK, v. 2.0, 2009.

BPM CBOK - ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSIONALS (ABPMP). Guia para Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento - Versão 2.0, 2009.

PRADO, Darci Santos do. Planejamento e Controle de Projetos. Série Gerência de Projetos. Nova Lima (MG), INDG, 2004.

Material preliminar do PMBOK® 5ª Edição - 2013 colhidos no website da Revista Mundo Project e no website do consultor Ricardo Vargas. Visitados em Dezembro de 2013.

quarta-feira, 2 de outubro de 2013

Padrões de Gerenciamento de Projetos - PRINCE2, ISO 21500:2012 e PMBOK

2 PADRÕES PARA GERENCIAMENTO DE PROJETOS

Dentre os padrões mundiais para gerenciamento de projetos, os mais conhecidos são PMBOK^®, PRINCE2™ e ISO 10006:2003(ISO 21500:2012).

O padrão alemão ZOPP será abordado em uma atualização futura deste post.

2.1 PRINCE2™

PRINCE2™ (PRojects IN Controlled Environments) ^{^[1]} é um padrão para gerenciamento de projetos desenvolvido e usado extensivamente pelo governo do Reino Unido e no setor privado internacional.

O PRINCE2™ surgiu em 1989 a partir do PROMPTII, o qual por sua vez, foi criado em 1975 (através de iniciativas da Central Computer and Telecommunications Agency do Reino Unido), tendo sido adotado em 1979 como padrão para gerenciamento dos projetos de sistemas de informação governamentais do Reino Unido. O PRINCE2™ foi lançado como um padrão para gerenciamento de projetos pelo governo britânico em 1996.

O padrão PRINCE2™ isola o gerenciamento do projeto (ex.: aspectos ligados ao escopo, tempo, custo, qualidade, riscos, benefícios, tolerâncias, etc.) das contribuições especializadas (o esforço para realizar o produto, ex: design, construção, etc.). Assim, os métodos de produção que envolvem aspectos especializados são facilmente integrados com o método PRINCE2™, formando um framework completo para o projeto.

Este padrão é composto por um conjunto de princípios, um conjunto de temas de controle, um ciclo de vida dos processos e orientações no uso do método com a adequação ao ambiente do projeto. É um padrão adaptável a qualquer tipo ou tamanho de projeto, cobrindo o gerenciamento, o controle e a organização. Um projeto PRINCE2™ tem as seguintes características:

• Controle e organização do início ao fim;

• Revisão de progressos baseado nos planos e no business case;

• Pontos de decisão flexíveis;

• Gerenciamento efetivo de qualquer desvio do plano;

• Envolvimento da gerência e das partes interessadas em momentos-chave durante toda a execução do projeto;

• Canais de comunicação otimizados entre a equipe do projeto e o restante da organização.

Os princípios são orientações obrigatórias e boas práticas que determinam se o projeto está sendo genuinamente gerenciado de acordo com o método PRINCE2™. São sete princípios:

1. Justificativa contínua do negócio (Business Case).	2. Aprendizado com a experiência.
3. Papéis e responsabilidades definidos.	4. Gerenciamento por estágios.
5. Gerenciamento por exceção.	6. Foco no produto.
7. Adequação ao ambiente do projeto.

Sem a aplicação de qualquer um dos princípios acima, o projeto não estará utilizando o padrão PRINCE2™ em sua totalidade.

Os temas descrevem aspectos do gerenciamento de projeto que devem ser tratados continuamente e em paralelo ao longo de toda a duração do projeto. Também são sete temas:

· Business Case.	· Organização.	· Qualidade.
· Planos.	· Risco.	· Mudança.
· Progresso.

Estes temas explicam o tratamento do PRINCE2™ para as várias áreas de gerenciamento de projetos.

Figura 3- O ambiente do projeto segundo o padrão PRINCE2.

Os processos são percorridos de acordo com as etapas ao longo do ciclo de vida do projeto. São sete os processos:

1. Starting Up a Project (SU).	2. Directing a Project (DP).	3. Initiating a Project (IP).	4. Managing a Stage Boundary (SB).
5. Controlling a Stage (CS).	6. Managing Product Delivery (MP).	7. Closing a Project (CP).

Abaixo, temos um modelo adaptado do framework PRINCE2^TM:

Figura 4- Diagrama adaptado do framework PRINCE2.

Cada processo fornece listas de verificação de atividades, com recomendações de produtos (de gerenciamento de projetos (ex.: business case), de descrição de produtos, de relatórios, de registros, de notas de lição e outros) e as responsabilidades relacionadas.

A adequação ao ambiente particular do projeto é proporcionada pelo PRINCE2™ através de um framework flexível que pode ser ajustado a qualquer tipo e porte de projeto. O PRINCE2™ não é uma solução de tamanho único, mas sim um framework flexível que pode ser adequado a qualquer tipo e porte de projeto.

Como benefícios da utilização do padrão PRINCE2™, podem ser citados os seguintes:

§ Incorporação de práticas de governança em projetos estabelecidas e comprovadas como melhores práticas;

§ Possibilidade de aplicação em qualquer tipo projeto e em qualquer tipo de organização;

§ Amplo reconhecimento e aceitação no cenário internacional com planos baseados nas necessidades das equipes de projetos;

§ Promoção de uma linguagem comum, possibilitando um vocabulário único a todos os participantes do projeto e estabelecimento de comunicação efetiva;

§ Promoção do reconhecimento explícito dos Papéis e Responsabilidades. Dessa forma os participantes compreendem os papéis e necessidades de cada um, permitindo a existência de uma estrutura definida para responsabilização, delegação, autoridade e comunicação.

§ Direcionamento no foco do Produto (entregas), que clarifica (para todas as partes interessadas) o que o projeto irá entregar, o porquê, quando, por quem e como. Com esse foco estabelecido, os planos são desenhados para satisfazer os diferentes níveis da equipe, melhorando a comunicação e o controle;

§ Implementação da Gestão por Exceção (uma de suas bases), que possibilita a eficiência e eficácia na utilização do uso e suporte da gestão executiva;

§ Estabelecimento de estratégias baseadas nos critérios de viabilidade/executabilidade do Business Case, de forma a consolidar os benefícios do projeto;

§ Possibilidade de aprendizado e melhoria contínua, promovendo o aumento da Maturidade no Gerenciamento dos Projetos;

O programa de certificação para o padrão PRINCE2™ é globalmente gerido pelo APM Group^{^[2]}. As duas principais certificações são: PRINCE2 Foundation e PRINCE2 Practitioner. Aproximadamente 1.500 pessoas prestam, mensalmente, os exames de certificação em mais de 120 centros de treinamento credenciados PRINCE2™ pelo mundo, inclusive no Brasil.

Atualmente o PRINCE2™ é adotado como padrão para todos os projetos do governo britânico e amplamente utilizado pela iniciativa privada na Europa, África, Oceania e Estados Unidos da América. Considerado um dos métodos de gerenciamento de projetos mais utilizado no mundo, conta com mais de 250 mil profissionais certificados,

No Brasil, a metodologia PRINCE2™ já vem sendo utilizada por diversas organizações e profissionais, sendo crescente a sua adoção como método de gerenciamento de projetos.

2.2 ISO 10006:2003 e ISO 21500:2012

A ISO 10006:2003 (Quality Management: Guidelines to Quality in Project Management) é uma norma desenvolvida pela ISO^{^[3]} específica para gerenciamento de projetos. A norma ISO 10006:2003 não é um guia para "gerenciamento de projetos" em si, mas uma orientação sobre a qualidade necessária nos processos de gerenciamento de projetos.

A orientação na qualidade de processos de gerenciamento dos projetos, segundo a ISO 10006:2003 deve buscar assegurar, entre outros objetivos:

• Que as necessidades dos clientes sejam entendidas e entregues;

• Que as necessidades dos stakeholders (partes interessadas) sejam compreendidas e avaliadas;

• Que a política de qualidade seja incorporada à gerência da organização, tendo como norte os objetivos estratégicos e a busca de resultados.

A norma ISO 10006:2003 aborda o gerenciamento de projetos, mas como a própria norma diz, não é um guia mas a reunião de diretrizes que devem ser usadas para manter a qualidade em projetos. Essas diretrizes podem ser adaptadas para atender a um projeto em particular e/ou específico. É aplicável a projetos de complexidade variada, pequenos ou grandes, de curta ou longa duração, em diferentes ambientes, e independentemente do tipo de produto ou processo envolvido.

A ISO 10006:2003 classifica os processos de gerenciamento de projetos em:

1. Processo estratégico

2. Processos de gerenciamento de interdependências

3. Processos relacionados ao escopo

4. Processos relacionados ao tempo

5. Processos relacionados ao custo

6. Processos relacionados aos recursos

7. Processos relacionados ao pessoal

8. Processos relacionados à comunicação

9. Processos relacionados ao risco

10. Processos relacionados aos suprimentos

A ISO 10006:2003 é um documento de orientação, não se destinando a ser utilizada para fins de obtenção de certificação/registro.

Uma vez que o gerenciamento de projetos continua crescendo e ganhando reconhecimento mundialmente, a ISO determinou que um novo padrão internacional era necessário.

A norma ISO 21500:2012 (Guia para o Gerenciamento de Projetos) foi desenvolvida a partir de 2007 e finalizada em 2012, e representa a modernização da norma ISO 10006:2003. No Brasil foi publicada como ABNT^{^[4]} NBR ISO 21500:2012 – Orientações para o Gerenciamento de Projetos.

A ABNT NBR ISO 21500:2012 propõe dar suporte na transferência de conhecimentos entre projetos e organizações, resultando na melhoria das entregas dos projetos e ainda:

· Facilitar processos de concorrência mais eficientes, especialmente em grandes projetos internacionais através do uso de terminologia de gerenciamento de projeto consistente;

· Permitir que as organizações multinacionais coordenem seus sistemas e processos de gerenciamento de projetos;

· Facilitar a mobilidade do pessoal de gestão de projetos e a sua capacidade para trabalhar em projetos internacionais;

· Fornecer um quadro de princípios genéricos de gerenciamento de projeto e processos que poderiam ser desenvolvidos para o avanço da profissão de gerenciamento de projeto e das organizações.

[1] PRINCE2^®(Projects in Controlled Environment) – Para saber mais acesse: http://www.prince-officialsite.com/AboutPRINCE2/AboutPRINCE2.aspx

[2] O APM Group é um organismo internacional de acreditação, certificação e aplicação de exames especializada em certificação para indivíduos, organizações e softwares. – Para saber mais acesse: http://www.apmgroupltd.com/

[3] ISO (International Organization for Standardization) – Para saber mais acesse: http://www.iso.org/iso/home/about.htm

[4] ABNT – Associação Brasileira de Normas Técnicas. Para saber mais acesse: http://www.abnt.org.br/default.asp

---------------------------------------------------------------------------------------------------------

2.3 PMBOK^®

O PMBOK^® é o padrão adotado pela Polícia Federal para o gerenciamento de seus projetos.

O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK^®)^{^[1]} é um padrão reconhecido para a profissão de gerenciamento de projetos, que descreve normas, métodos, processos e práticas estabelecidas, sendo publicado e mantido pelo PMI. O Guia PMBOK^® também serve como repositório das boas práticas adotadas na área de gerenciamento de projetos, fornecendo diretrizes para a gestão de projetos individuais.

Uma boa prática pode ser definida como uma ação gerencial que estabelece parâmetros para a boa condução de um projeto. Entretanto, o conhecimento e as práticas inerentes a estas ações gerenciais não devem ser aplicados indistintamente a todo e qualquer projeto. O uso de uma boa prática qualquer sempre deve levar em conta a sua adequação e grau de profundidade de aplicação em dado projeto.

O Guia PMBOK^® foi publicado pela primeira vez pelo PMI como um white paper em 1983 (Project Management Journal), na tentativa de documentar e padronizar as práticas que são normalmente aceitas no gerenciamento de projetos. Este white paper foi revisado e atualizado entre 1984 e 1987, através de seis comitês temáticos do PMI, sendo publicado em 1987, na forma de um documento independente chamado “O conjunto de conhecimentos em gerenciamento de projetos”.

A primeira edição definitiva do guia foi publicada em 1996, seguida pela segunda edição no ano 2000. Em 2004, o Guia PMBOK^® – 3ª Edição foi publicado com as maiores mudanças, considerando as edições anteriores. A 4ª Edição foi lançada em 2008. A última versão do Guia PMBOK^® é a 5ª Edição, que foi publicada em abril de 2013 (em Inglês).

O Guia PMBOK^® também fornece e promove um vocabulário comum (não exaustivo) para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos.

O guia PMBOK^® é baseado em processos e subprocessos e procura descrever de forma organizada o trabalho a ser realizado durante o ciclo de vida de um projeto (é um guia e não uma metodologia), utilizando abordagem semelhante à empregada por outras normas como a ISO 21500:2012 e CMMI [2].

Os processos e grupos de processos descritos no PMBOK^® se relacionam e interagem durante o ciclo de vida do projeto. A descrição de cada um destes processos é feita em termos de:

· Entradas (documentos, planos, desenhos etc.);

· Ferramentas e técnicas (que se aplicam às entradas);

· Saídas (documentos, produtos etc.)

Em sua 5ª Edição (2013), o PMBOK^® relaciona 47 processos de gerenciamento de projetos, distribuídos em 05 grupos de processos (Iniciação, Planejamento, Execução, Monitoramento e controle e Encerramento).

Tabela 1- Os 05 grupos de processos em gerenciamento de projetos e seus 47 processos - PMBOK (2013). Adaptação

INICIAÇÃO 4.1 Desenvolver Termo de Abertura 13.1 Identificar as Partes Interessadas (Stakeholders)
PLANEJAMENTO 4.2 Desenvolver Plano de Gerenciamento do Projeto 5.1 Planejar Gerenciamento do Escopo 5.2 Coletar Requisitos 5.3 Definir Escopo 5.4 Criar EAP – Estrutura Analítica do Projeto 6.1 Planejar Gerenciamento do Tempo 6.2 Definir Atividades 6.3 Definir Sequência de Atividades 6.4 Estimar Recursos das Atividades 6.5 Estimar Durações das Atividades 6.6 Desenvolver Cronograma 7.1 Planejar Gerenciamento dos Custos 7.2 Estimar Custos 7.3 Determinar Orçamento 8.1 Planejar Gerenciamento da Qualidade 9.1 Planejar Gerenciamento de Recursos Humanos do Projeto 10.1 Planejar Comunicação 11.1 Planejar Gerenciamento dos Riscos 11.2 Identificar Riscos 11.3 Realizar Análise Qualitativa 11.4 Realizar Análise Quantitativa 11.5 Planejar Respostas aos Riscos 12.1 Planejar Gerenciamento das Aquisições 13.2 Planejar Gerenciamento das Partes Interessadas (Stakeholders)
EXECUÇÃO 4.3 Dirigir e Gerenciar a Execução 7.4 Controlar Custos 8.2 Realizar Garantia de Qualidade 9.2 Mobilizar Equipe do Projeto 9.3 Desenvolver Equipe do Projeto 9.4 Gerir Equipe do Projeto 10.2 Distribuir Informação 12.2 Conduzir Aquisições 13.3 Gerenciar Engajamento das Partes Interessadas (Stakeholders)	MONITORAMENTO E CONTROLE 4.4 Monitorar e Controlar o Trabalho 4.5 Realizar Controle Integrado de Mudanças 5.5 Validar Escopo 5.6 Controlar Escopo 6.7 Controlar Cronograma 8.3 Controlar Qualidade 10.2 Relatar Desempenho 11.6 Monitorar e Controlar Respostas aos Riscos 12.3 Administrar Aquisições 13.4 Controlar Engajamento das Partes Interessadas (Stakeholders)
ENCERRAMENTO 4.6 Encerrar Projeto ou Fase 12.4 Encerrar Aquisições

[1] Project Management Book Of Knowledgement.

[2] O CMMI (Capability Maturity Model Integration) é um modelo de referência da Universidade Carnegie Mellon, que procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

Papo de Projeto