A ambição de todo PROJETO é, um dia, se transformar num PROCESSO
Toda vez que explicíto esta aberração das definições clássicas de PROJETO, as pessoas me agradecem, alegando que nunca haviam pensado sobre este prisma. Então resolvi escrever sobre isto aqui em nossa newsletter. Vamos a meus argumentos e reflita você mesmo.
Definições clássicas
De acordo com o PMI (Project Management Institute), órgão internacional que legisla sobre as boas práticas de Gestão de Projetos, que criou o PMBOK (Project Management Body of Knowledge), que é a base da certificação PMP (Project Management Professional), PROJETO tem a seguinte definição:
Um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo cuja característica fundamental é ter um início e um fim bem definidos e ser executado com recursos limitados ou pré estabelecidos (tempo, dinheiro, pessoas) para atingir objetivos específicos.
De acordo com a ABPMP (Association of Business Process Management Professionals), órgão internacional que legisla sobre as boas práticas de Gestão de Processos de Negócio, que criou o BPM-CBOK (Business Process Management – Common Body of Knowledge), que é a base das certificações CBPP (Certified Business Process Professional), CBPA (Certified Business Process Associate) e CBPL (Certified Business Process Leader), PROCESSO tem a seguinte definição:
Um conjunto de atividades sequenciadas que entregam valor e que são iniciados por eventos externos e que são formados pela combinação de todas as atividades e suporte necessários, para produzir e entregar um objetivo, resultado, produto ou serviço, independente de onde a atividade seja executada. Esse contexto inclui um conjunto definido de atividades ou comportamentos realizados por humanos, sistemas ou uma combinação dos dois. É definido como um trabalho ponta-a-ponta que entrega valor aos stakeholders. A noção de trabalho ponta-a-ponta é crucial, já que envolve todo o trabalho, cruzando qualquer fronteira intra ou interorganizacional, necessário para entregar de fato valor.
Exemplos clássicos, nem sempre corretos
Como exemplo clássico de um PROJETO normalmente referem-se a um edifício (prédio), empreendimento que caracteriza um esforço temporário dotado de começo e fim e cuja execução é realizada com recursos limitados ou pré estabelecidos. Para isto justifica-se, sempre, utilizar-se do PMBOK como guia de referência para sua consecução.
Como exemplo que eu sempre dou a um PROCESSO seria uma internação de uma pessoa a um hospital, ao que todos prontamente aceitam ser sim um exemplo legítimo de PROCESSO, mas não de PROJETO, justificando-se utilizar-se do BPM-CBOK como guia de referência para sua consecução mais exemplar.
Mas é exatamente aí que eu me intrometo fazendo o contraponto: uma internação também atende aos pressupostos da definição clássica de um projeto. Ela (a internação) é um esforço temporário para aquele paciente, tem um começo (gatilho motivador de algum procedimento somente executável num ambiente hospitalar), um fim (alta médica ou óbito) e também submete-se a realização mediante recursos limitados ou pré estabelecidos.
Por que então uma internação é sempre associada a um PROCESSO e não a um PROJETO?
Na minha humilde opinião é porque a definição clássica de PROJETO é insuficiente para diferenciar-se da definição de PROCESSO. Todos os PROCESSO, sem exceção, considerando cada evento em si, é também um esforço temporário, dotado de começo e fim e submisso a recursos limitados ou pré estabelecidos. A diferença básica não é esta!
A característica básica de um PROJETO é que ele precisa obedecer as definições clássicas do PMBOK, mas precisa também estar sendo feito pela primeira vez, algo até então nunca realizado, portanto algo novo e que ainda não se refere a uma atividade repetitiva. Quando ele tornar-se repetitivo, que deveria ser sua principal ambição, torna-se então um PROCESSO e, portanto, muda seu guia referencial de exemplaridade para o BPM-CBOK.
Nesta definição, para uma construtora, um prédio de alto padrão que é feito recorrentemente (como rotina), mesmo que cada prédio seja muito diferente do outro (até porque uma internação também sempre é muito diferente da outra) não é mais um PROJETO e sim um PROCESSO.
A primeira vez (ou as primeiras vezes) que aquela específica construtora fez um prédio de alto padrão, aí sim aplica-se o PMBOK, pois trata-se de um PROJETO sendo feito pela primeira vez, ainda em fase de laboratório, e que não transformou-se ainda numa rotina para aquela específica construtora. A medida que aquela construtora torna-se especialista em construir prédios de alto padrão, portanto torna-se repetitivo aquele tipo de empreendimento (por mais que cada prédio seja diferente um do outro), não é mais adequado utilizar como guia o PMBOK, mas já cabe atender a ambição daquele PROJETO de tratá-lo como um PROCESSO, utilizando como guia outro referencial mais adequado, o BPM-CBOK.
Se esta construtora migrar para fazer também prédios populares, as primeiras vezes que o fizer será cabido utilizar o guia PMBOK, mas com o tempo, transformar-se-á num processo e adequado será migrar novamente para o guia BPM-CBOK.
Da mesma forma o inverso: se um hospital, cuja vocação seja vocação seja cirurgias ortopédicas, nas primeiras cirurgias será considerado um PROJETO (aderente ao guia PMBOK), mas ao longo do tempo transformar-se-á num PROCESSO (aderente ao BPM-CBOK). Se o hospital começar a dedicar-se a fazer cirurgias cardíacas ou de cabeça e pescoço, nas primeiras experiências é sugerido utilizar-se os pressupostos de PROJETO, mas com o tempo, quando transformar-se em algo mais repetitivo, rotineiro, a ambição do PROJETO se concretiza e ele transforma-se num PROCESSO e merece novo guia de referência.
O que precisamos fazer a respeito?
Vejo com muita frequência empresas aplicando os conceitos de PROJETOS (via PMBOK) a empreendimentos ou iniciativas que são feitos a anos e sequer sabem que perdem eficiência, eficácia e efetividade por sequer conhecerem as boas práticas de PROCESSOS descritas no BPM-CBOK.
Nenhum evento de cada PROCESSO é idêntico ao outro, cada evento tem sua peculiaridade, e considerar cada evento um PROJETO é um erro crasso. Corrigir esta deformação é emergencial e nós estamos aqui para conversar e orientar sobre como distinguir uma coisa da outra e conseguir o máximo de resultados em cada aplicação específica.
