Gerenciando Projetos

PMBOK 2004 em português

2006-05-07T18:14:00.000-07:00

Título: PMBOK 2004 em português	08-02-2007
URL: private:stream	14:13:23

Buscando na internet, descobri este material interessante que repasso a todos.
É o Project Managament Base of Knowledgment versão 2004 totalmente em português.
Faça o download visitando a página linkada:

http://luis.afonso.googlepages.com/pmbok2004emportugu%C3%AAs

Página 1 de 1

Projetos e a hierarquia da empresa

2006-04-24T10:37:00.000-07:00

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

Cem Regras para Gerenciamento Projetos (da Nasa)

2006-04-21T19:51:00.000-07:00

Antes de começar a falar em metodologias de gerenciamento de projetos, tais como PMI, gostaria de lembrar que a ciência de projetos é, antes de tudo, o estudo de sua prática, uma praxiologia.
Porque "gerenciar projetos" é um assunto que só se pode conhecer a fundo FAZENDO.
E só pelo estudo de sua 'praxis' é que se pode mapear quais os fatores mais comuns para levá-los ao sucesso. Mas esta lista não é determinística.

Isso significa que um projeto de sucesso pode ou não ser obtido através da dedicada aplicação dos métodos mais conhecidos.
Sempre existe um indeterminismo ligado à sua implementação. Nisso a ciência de projetos se assemelha à economia - também ela uma outra ciência baseada no estudo das práticas já adotadas.

Neste sentido, o texto que cito a seguir é uma preciosa contribuição ao entendimento em profundidade dos diversos componentes técnicos, pessoais/motivacionais, ambientais e organizacionais envolvidos no processo de gerenciamento de projetos.

Trata-se das "Cem Regras para Gerenciamento Projetos (da Nasa)",
produzido por Jerry Madden, diretor associado da Diretoria de Projetos de Vôo Espacial da Nasa e que tive a paciência de traduzir.
Como o material é bastante extenso, não comportado neste formato de blog, criei um website dedicado a ele. Aqui está o endereço: http://luis.afonso.googlepages.com/cemregrasparaprojetos Aproveitem!!

Inaugurando o blog

2006-04-18T16:17:00.000-07:00

Ultimamente muito se tem falado sobre gerenciamento de projetos. Podemos ver o grande interesse a respeito do assunto pela grande demanda de pessoas participando de cursos de capacitação em metodologias novas como PMI ou mesmo CMM.

Neste espaço quero compartilhar algumas experiências acumuladas em mais de 15 anos trabalhando com projetos especialmente na área de tecnologia da informação, seja na implantação de ferramentas como ERP (enterprise resource planning) e mesmo com times de desenvolvimento de customizações ou novo aplicativos .

Bem vindos!