Projetos e a hierarquia da empresa

Um dos pontos mais importantes que a metodologia por si é a definição do container organizacional que será o responsável pela  administração de projetos em cada empresa.
A metodologia  PMI, por exemplo propõe uma série de alternativas possíveis, todas com seus prós e contras, sobre o posicionamento organizacional da administração ou gerenciamento de projetos. Algumas delas são:

- Funcional
- Matricial
- Projetizada

Em minha concepção, a definição não pode ser estruturada sem uma análise adequada do organograma "oficial" ( o organograma formal, repassado para documentos internos ou intranet, por exemplo) e  o organograma  real (ou seja o real fluxo da tomada de decisões  na empresa). O  gerenciamento de projetos tem de estar  firmemente conectado  com estas duas  fontes de demandas e decisões corporativas.  A falta de aderência a uma delas, levará fatalmente ao projeto a um descolamento  ou um desvio dos objetivos da corporação como um todo.

Mas vamos aos detalhes:

A definição "funcional" tem muitos problemas. Os projetos envolvem mais de uma área e portanto são matriciais por definição. Colocá-los sob a mesmo gerenciamento têm ganhos com relação à razão dedicação ao projeto/dedicação à rotina (sendo o mesmo gerente das duas funções ele consegue estabelecer prioridades de forma mais fácil) mas têm problemas no que concerne à escalação da equipe.

Definir a equipe prioritáriamente restrita a uma área pode fazer com que nem sempre a pessoa mais adequada seja responsabilizada por uma determinada tarefa. A sub-utilização do recurso (no início) bem como sua utilização acima da capacidade nominal (do meio para o fim de um projeto, geralmente) gera um desnivelamento da utillização do recurso.

Outro dado importante é que um projeto definido pela estrutura funcional quase sempre acaba em um projeto matricial. Somente projetos muito pequenos podem são definidos e tocados somente dentro de uma área. A própria definição de processos (falarei sobre a questão projetos X processos mais tarde) prevê o inter-relacionamento dos diferentes departamentos. Fatalmente de uma hierarquia "funcional" acabaremos em uma "matricial".

Mas esta passagem não é fácil. Como um gerente de uma área pode começar a gerenciar um projeto que têm seus recursos alocados em outra área? Será necessária a adoção de uma abordagem mais corporativa. Aí pode entrar em cena o "project expeditor".

Inicialmente um project expeditor tem somente a função de manter a organização e os tomadores de decisões, entre outros, informados sobre o rumos do projetos e as necessidades de decisão ou ação coordenada.

Num segundo estágio, muitas vezes em função de agenda e choque de prioridades, o "project expeditor" poderá ser elevado `a categoria de  "project coordinator". Neste caso ele será de fato o gerente coorporativo do projeto, começando também a tomar decisões sobre o projeto.

Isto é claramente visível num processo de implantação típico de ferramentas de gestão corporativas, os famosos ERP (Enterprise Resource Planning),  nos quais o gerente de tecnologia passa de sponsor à "project expeditor" e , finalmente  - em função da necessidade de decisões críticas e alocação de recursos de forma prioritária - para "project coordinator".

A questão do conhecimento da tecnologia é o fator primário, mas de fato um coordenador de projeto ERP acaba sendo ao final um gestor de processos. Pois a implementação destas ferramentas de gerenciamento implicam na mudança do fluxo de relacionamento das áreas e seus clientes externos e internos.

O conflito acaba florescendo quando os gerentes funcionais acabam finalmente percebendo a profundidade das mudanças que a adoção destas ferramentas acabam provocando e tentam então se situar "pari passu" ao status atual do projeto.

Estes conflitos acabam muitas vezes colocando todo o processo à deriva, pois quanto mais perto do fim do projeto, mais críticas são as necessidades de decisão, que - neste caso - acabam travadas por uma definição de papéis ou matriz inicialmente fraca.

Muitos fornecedores de solução ERP sugerem ainda um outro forum de tomada de decisões para atenuar possíveis conflitos. A instituição do que se chama de "steering committee" - formado por usuários-chave, consultores externos, gerentes internos,  sponsors e stakeholders - que é o forum para tratar de impasses, conflitos ou outras decisões importantes. Neste caso o "project coordinator" acaba sendo o próprio comitê e não uma pessoa designada.

Quanto à empresa totalmente projetizada, acho que é um modelo bastante conceitual para que se possa comentar com mais propriedade. É claro que a NASA  (ver o post anterioro) é um destes casos. Mas seu perfil não é absolutamente um padrão que possa ser definido.

Até mais!!