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!!
