Enquadramento

No atual ambiente de imprevisibilidade, alta volatilidade e instabilidade que caracteriza a dinâmica em que operam as organizações, é hoje incontestável que para sobreviverem deverão ir além da já de si exigente continuidade do negócio mas antes conseguirem diferenciar-se na sua capacidade de o transformar sustentadamente. Com efeito, se o contexto de operação é fundamental para assegurar o dia-a-dia da organização é todavia por meio da mudança que continuamente se reinventa e fortalece, (re) criando produtos e serviços, definindo novos métodos de trabalho e/ou alterando processos produtivos ou organizacionais. Deste modo, surge então o conceito de projeto como ação concretizadora da mudança e a forma por excelência para implementar as estratégias da organização na prática, à qual é essencial a Gestão de Projeto enquanto conjunto de conhecimentos, skills, técnicas e ferramentas que permitem a condução profissional e profissionalizante no modo como são geridos os projetos.

Porém, se o forte crescimento e divulgação desta disciplina vem corroborar os largos benefícios que traz à Gestão, entre os quais se incluem a previsibilidade no delivery e alinhamento com o negócio e o rigor no cumprimento dos objetivos do projeto, não deve assumir-se uma Gestão de Projeto igual para todos mas antes deverá ser feito um esforço de adequabilidade à maturidade da organização nesta matéria bem como à tipologia ou dimensionamento dos projetos em causa.

Tal como nem todos aprendemos a andar ao mesmo tempo, também as organizações evoluem a ritmos diferenciados no seu percurso até à excelência em Gestão de Projeto. Este percurso designa a sua maturidade, isto é, o estado dos processos de Gestão de Projeto da organização quando comparados com as melhores práticas internacionais, sendo que são reconhecidos cinco patamares de maturidade, abaixo explanados:

  • Ad hoc – estágio inicial em que os processos são realizados de forma reativa, inconsistente e imprevisível, casuisticamente e sem controlo
  • Definido – neste estado, verifica-se que existem processos e templates definidos, com base em standards e referências internacionais, apesar da sua utilização ser incipiente
  • Normalizado – trata-se de um patamar em que os processos estão formalizados e normalizados, ou seja, verifica-se um uso generalizado daquilo que está definido
  • Medido – atingido este estádio, a organização possui indicadores sobre os seus principais processos e portanto está consciente do seu desempenho
  • Controlado – neste patamar a organização aceita o resultados dos indicadores que observa e o processo é considerado gerido.
  • Optimizado – neste último patamar, o foco assenta na optimização progressiva conducente à melhoria contínua dos processos de Gestão de Projeto.

É neste cenário, nomeadamente, enquanto factor primário mas não exclusivo que permite distinguir uma organização que se inicia na Gestão de Projeto daquelas que procuram avançar a sua maturidade neste domínio, que se destaca a importância da existência e seguimento de uma metodologia na organização.

A importância dos standards

A uniformização dos processos, procedimentos ou ferramentas tem por base uma necessidade crítica – prevenir a cada momento a reinvenção da roda e, dessa forma, poupar tempo e energia, além de reduzir o rework e aumentar a qualidade. Ademais, a existência de um standard na organização permite que todos falem a mesma linguagem, retira ambiguidade e constitui-se como um factor de estabilidade interna capaz de fornecer as principais orientações de conduta ou modus operandis em contexto de projeto.

A realidade é que, apesar das técnicas hoje em uso e cada vez mais sofisticadas formarem uma sólida e fundamental base para a gestão de projetos e para o que é a Gestão de Projeto enquanto disciplina, são ainda insuficientes para que, com uma metodologia by the book, garantirem o sucesso dos projetos ou responderem eficazmente à dinâmica e incerteza que envolvem.

Framework vs Metodologia

Comecemos por esclarecer o âmbito de uma metodologia. Não raras vezes, verifica-se um uso inadequado dos termos “framework” ou “metodologia”, sendo estes frequentemente usados de forma indistinta. Com efeito, não é uma distinção simples, embora possamos aqui considerar aquela trabalhada por Benjamin L.

Tomhave (2005), que se debruçou sobre esta taxonomia. De acordo com este autor, framework é uma construção fundamental e geral que define pressupostos, conceitos, valores e práticas, incluindo orientações para a sua própria implementação.

O mesmo autor apresenta-nos o conceito de metodologia como uma construção mais prescritiva, dirigida a um dado público, que define de forma específica práticas, procedimentos e regras para a implementação ou execução de uma tarefa ou função concreta.

Deste modo, para um melhor entendimento, podemos avançar, a título de exemplo, que o PMBOK® Guide é uma framework e o PRINCE2® é uma metodologia. Ainda, a metodologia desenvolvida para a organização pode ter por base uma framework ou outra metodologia já existente.

Assim, uma metodologia é uma adequada, repetível, estandardizada e documentada colecção de processos, ferramentas, técnicas e templates para a gestão de projetos, que deve considerar os seguintes pontos na sua elaboração:

  • Refletir o tamanho, complexidade e indústria do projeto
  • Ser baseada nas melhores práticas
  • Ser facilmente localizável e compreensível por todos os membros da equipa
  • Estar sujeita ao processo de melhoria contínua
  • Ser flexível e escalável o suficiente para ser aplicável a qualquer tipo de projeto
  • Focar-se na abordagem mais favorável para o projeto
  • Porém, é imprescindível recordar também o que uma metodologia não deverá ser:
  • Uma metodologia não é um arranjo rápido
  • Uma metodologia não é uma solução temporária
  • Uma metodologia não é um livro de receitas

Independentemente da metodologia utilizada, é hoje um conhecimento generalizado de que “um tamanho não serve a todos” e, se nos tempos de Taylor era esta a prática, hoje em dia não conseguir o fit adequado da metodologia pode ser um entrave ao sucesso dos projetos da organização.

O que mudou desde Taylor?

Os princípios da Administração Científica 5 concebidos por Frederick Taylor preconizavam uma maneira única e óptima de fazer as coisas, que encontrou a sua mais reconhecida aplicação nas fábricas de montagem e de produção em massa.

Porém, muito mudou desde a era industrial, em que o ambiente organizacional caracterizava-se por ser estável e previsível, o cliente assumia um papel indiferenciado e as tarefas eram predominantemente manuais, rotineiras e simples. Neste cenário, foi facilmente aceitável e reconhecida como mais-valia a existência de padrões, mas hoje, num ambiente que é dinâmico e altamente imprevisível, onde o cliente é rei e as tarefas exigem habilidade mental de tão únicas e complexas, a existência de um padrão pode ser castradora e a pouca elasticidade do processo pode dificultar o progresso do projeto.

Quando o processo dificulta o progresso

Alguém escreveu que “PMBOK® é trilha (música), não trilho (caminho) ”. Sendo de uma simplicidade notável, esta sentença encerra em si uma verdade importante: deve ser a metodologia a adaptar-se ao projeto e não o projeto a adaptarse à metodologia. Com efeito, recorde-se que cada projeto apresenta características únicas e diferenciadas, podendo variar largamente ao nível da sua complexidade, dimensão ou risco, entre outros.

Muitas vezes a metodologia é seguida literal e cegamente, como copy-paste do PMBOK® Guide e sem espaço para sair do seu trilho, o que acaba por conduzir a uma Gestão de Projeto robótica e pouco flexível para acomodar as habituais dinâmicas de um projeto, além de poder originar resistência da equipa a uma estrutura demasiado pesada, burocrática e administrativa. Saliente-se que os processos previstos na metodologia não são um fim em si mesmos, mas antes têm como objetivo nuclear facilitar a entrega do projeto, sob prejuízo de se atingir uma tal carga de trabalho administrativo que dificulta o progresso.

Esta miopia metodológica permite-nos observar um espectro de adopção que tem nos seus extremos o “Gestor de Projeto Heroico” e o “Gestor de Projeto Robótico”, descritos abaixo e que acentuam a necessidade de uma metodologia suficientemente ajustada ao portfólio de projetos – através de tailoring.

Aquele que melhor se adapta à mudança

“Não é a mais forte nem a mais inteligente das espécies que sobrevive mas aquela que melhor se adapta à mudança”, célebre afirmação de Darwin, poderia igualmente ser uma frase sobre o processo de tailoring na Gestão de Projeto. De facto, é disso que falamos quando referimos o tailoring – a capacidade de adaptar ou adequar a metodologia às características do projeto e ao seu contexto e garantir que os projetos são geridos com a quantidade certa de documentação e controlo. Com efeito, ressalve-se que a Gestão de Projeto não deve servir para “dar trabalho” mas antes para facilitar o modo como o trabalho se desenvolve.

Ora, um princípio subjacente a este enunciado é o de que o trabalho de Gestão de Projeto deverá ser função do trabalho técnico envolvido, variando tipicamente entre 5% a 25% do esforço considerado, e possibilitando assim um eficaz balanceamento entre o esforço administrativo e o esforço projetizado.

Deste modo, o propósito do tailoring é então aquele de assegurar que a metodologia de gestão de projeto está relacionada com o ambiente do projeto e produto do projeto, nomeadamente, nos processos de negócio que o suportam, bem como assegurar que os entregáveis da Gestão de Projeto têm por base as dimensões que definem o projeto, como a sua escala, complexidade, importância, dependências ou risco do projeto, isto é, que os processos são apropriados para o projeto.

Uma abordagem comum é aquela do modelo UCP (uncertainty, complexity, pace), mais tarde adaptada e teorizada por Shenhar e Dvir (2007) , na abordagem a que chamaram de “gestão de projeto adaptativa”, representada em forma de diamante com quatro dimensões e respetivas configurações possíveis:

Novelty (Inovação) – representa a incerteza dos objetivos do projeto, a incerteza do mercado, ou ambos; mede como o novo produto do projeto é para clientes, utilizadores ou para o mercado em geral e, por implicação, o quão claros e bem definidos são os requisitos do produto; inclui três configurações: derivativa, plataforma e radical;

Technology (Tecnologia) – trata do nível de incerteza tecnológica, determinado pelo volume de tecnologia nova exigida; compreende quatro configurações: low-tech, médium-tech, high-tech e super-high-tech;

Complexity (Complexidade) – mede a complexidade do produto, tarefa e organização do projeto; tem três configurações possíveis: montagem, sistema e matriz;

Pace (Criticidade) – traduz a urgência do projeto, nomeadamente, quanto tempo há disponível para completar o trabalho; abarca quatro configurações: regular, rápida, crítica e blitz.

Cada uma destas dimensões afecta a gestão do projeto à sua maneira, desde o ciclo de desenvolvimento seguido à formalidade necessária ou não, a autonomia da equipa ou a intensidade de planeamento e revisões requeridas.

Assim, para uma correta aplicação do tailoring podem considerar-se os seguintes passos a garantir:

  1. Analisar o portfólio de projetos e aferir um conjunto de dimensões relevantes para a organização e que caracterizam tipicamente os projetos (ex.: custo, dimensão da equipa, nível de risco, clareza dos requisitos, etc.)
  2. Definir as configurações para cada um dos critérios (ex.: tomando como base o nível de risco, este pode ser elevado, médio ou reduzido)
  3. Estabelecer um conjunto não muito extenso (recomenda-se entre três a cinco) de tipologias de projeto (ex.: I, II, III, Complexidade A, B, C)
  4. Relacionar as tipologias estabelecidas com as dimensões e configurações consideradas (ex.: tipo I é aquele em que o projeto tem um risco elevado, uma equipa de reduzida dimensão e requisitos pouco claros)
  5. Definir os processos e entregáveis da metodologia aplicáveis às diferentes tipologias (ex.: um projeto da tipologia I, de elevado risco e pouco claro nos requisitos da solução, requer mais controlo e formalidade do que um projeto da tipologia III, em que os projetos têm reduzido nível de risco e requisitos suficientemente claros).

Como resultado de uma eficaz aplicação, o tailoring visa, entre outros, a obtenção dos seguintes:

  • Evitar redundância de informação
  • Otimizar a metodologia
  • Melhorar a qualidade da informação
  • Evitar resistência à implementação da metodologia

Por oposição, abaixo alguns sintomas críticos de que a metodologia pode não estar devidamente adequada ou de que o tailoring necessita de ser refinado:

  • A equipa de projeto não está a usar a metodologia
  • A equipa de projeto está modificar a metodologia por livre iniciativa
  • A metodologia aplica-se de igual maneira a todos os tipos de projeto.

Deste modo, cabe à organização, frequentemente alicerçada no papel do Project Management Office (PMO) enquanto entidade centralizadora das práticas de Gestão de Projeto, atentar cuidadosamente sobre a forma como a metodologia é seguida pelas equipas de projeto para que, atempadamente, consiga implementar as devidas ações preventivas e corretivas necessárias.

Refira-se que, como em qualquer outro processo da Gestão de Projeto, o processo de tailoring deve ser continuamente refinado em função das experiências obtidas, já que, como temos verificado, o que pode servir a um projeto não tem de obrigatoriamente servir a outro.

Conclusão

Tem sido atribuído ao conceito de tailoring cada vez maior importância, com as diferentes versões do PMBOK® Guide a reconhecer esta ênfase. Repare-se, a título de curiosidade, que a palavra “tailor” ou “tailoring” é usada 0 vezes na segunda edição, mas na última versão (exposure draft) surge já 11 vezes.

Além desta maior sensibilização para a importância deste conceito, assim exposta, é também consensual que o tailoring sobre a metodologia de Gestão de Projeto é um importante sinal de maturidade da organização em Gestão de Projeto.

Deste modo, em súmula, reforce-se que não é negado o valor fundamental do papel de uma metodologia de Gestão de Projeto enquanto alicerce das melhores práticas nas organizações mas tão-somente alerta-se para o perigo de a seguir cegamente e sem a capacidade de adaptação ao contexto do projeto.

Assim, as organizações necessitam sim de ter suficientes processos formais e estandardizados para alcançar eficiência e consistência, mas igualmente devem ter habilidade tal para se dotarem de suficientes processos informais e flexíveis que lhe permitam a capacidade de adaptação e de inovação.

Por Marisa Silva,
Agosto de 2012