10jun, 2013

Você esta pronto para utilizar o Project Server?

Muitos gestores pensam em implantar o Project Server, mas existem diversos pré-requisitos para que a implantação ocorra de forma correta e não se torne somente um “modismo” de mercado.
O Project Server oferece uma interface web (Project Web Access) muito amigável, e também a integração com ótimas ferramentas como o Project Professional, SharePoint, SQL e ferramentas de terceiros como o ERP, CRM, BI, etc.
Existem diversas funcionalidades de controle, e os ganhos são vistos em todas as áreas de conhecimento de gerenciamento de projetos.
Para implantar o Project Server, primeiramente deve verificar a necessidade da Organização, e assim, moldar o processo de acordo com a metodologia em gerenciamento de projetos. Os passos para a implantação do Project Server vão muito além destas informações, porém é um começo para alcançar este objetivo.

Segue algumas dicas antes de iniciar esta implantação.

Existe apoio em gerenciamento de projetos pela alta direção?
Raros projetos são realizados com sucesso se não houver um comprometimento com a alta direção.

Existe um PMO (Escritório de Projetos) em sua Organização?
Atualmente existem várias definições para um PMO, porém, caso existe um Project Server em sua Organização, provavelmente o PMO prestará suporte e acompanhará o andamento dos projetos.

A sua Organização possui uma metodologia de gerenciamento de projetos?
A falta de uma metodologia pode transformar uma ferramenta como o Microsoft Project em uma “planilha de calculo simples”, e a principal utilização desta ferramenta pode ser caracterizada como um simples “modismo” dentro de sua organização.

Sua Organização possui resistência a mudanças?
A maior dificuldade em projetos é a mudança na cultura organizacional, e isto afeta diretamente a forma que determinados departamentos / hierarquias enxergam o controle referente aos projetos. As pessoas podem influenciar os projetos de forma positiva ou negativa, e na implantação, é importante identificar os possíveis impactos e trabalhar neles.

Infra-estrutura

Quem analisará a infra-estrutura, o ambiente de hardware/software, LAN/WAN de conectividade e fatores geográficos necessários?
Este é o passo para definir o planejamento de capacidade. Dependendo do tamanho de sua Empresa, esta análise poderá ser realizada por uma pessoa ou mais pessoas, porém, é necessário que o patrocinador conheça tais limitações.

A equipe de TI conhece as tecnologias necessárias para implantar o Project Server?
A equipe de TI precisa adquirir o conhecimento de administração do Project Server, SharePoint e SQL para então, prestar um suporte adequado aos usuários.
O tempo de adaptação do ambiente é diferente de Empresa para Empresa, sendo assim, é necessário que exista um tempo estabelecido para realizar testes e homologação, para assim, entrar em produção.

Os gerentes de projetos possuem conhecimento do Project Professional?
O Project Professional é uma ferramenta muito poderosa e, em treinamentos que ministro, acompanho gerentes de projetos que utilizam somente o básico, não aproveitando os demais recursos que ela oferece.
Gostaria de deixar claro que não é necessário o conhecimento do Microsoft Project para Gerenciar Projetos, mas é a ferramenta mais utilizada no mercado para auxiliar no planejamento, execução, monitoramento e controle e encerramento dos projetos.

Como será o treinamento do Project Professional e Server para todos os níveis (Executivos, Gerente de Projetos, Gerente de Recursos, Lideres de Projetos, Equipe do Projeto, etc)?
Os Colaboradores produzem mais quando conhecem as ferramentas que trabalham.

Para que entenda os benefícios que esta ferramenta oferece, tomei a liberdade de incluir as principais funcionalidades do Project Server, tais como:

{gallery}EPM{/gallery}

Acompanhamento de tarefas
O recurso receberá sua atividade por email, e incluirá o andamento das atividades pelo Project Web Access, desta forma, o gerente de projetos utilizará seu tempo para outras atividades, transferindo a responsabilidade de incluir o progresso da atividade para o recurso.
O gerente de projetos aprovará ou rejeitará o andamento das atividades, sendo assim, o controle permanecerá com o gerente de projetos.

Meus Quadros de Horários
O gerente de projetos poderá controlar o horário de trabalho de sua equipe, tanto para trabalhos operacionais (podemos fazer uma analogia para o cartão de ponto dos funcionários) quanto para projetos (automaticamente preenchido pelo Project Server).
Questões e Riscos
Estas duas funcionalidades poderosas trabalham de forma integrada ao Project Server, e auxiliam os recursos interativamente ao controle dos Riscos e Questões no cronograma do projeto.
Risco: Evento previsível e/ou incerto que afete o projeto de forma positiva ou negativa.
Questões: Problemas identificados no decorrer do projeto.
Central de Projetos
A Central de Projetos permite uma visão completa de todos os projetos, com diversas visões para controle.
O controle de acesso é muito amplo, sendo assim, os Gerentes de Projetos vêem seus projetos e os Executivos podem acompanhar todos os projetos.
Propostas e Atividades
Os Gerentes de Projetos podem criar propostas (Termo de Abertura e Escopo Preliminar) e enviar para possíveis aprovações do patrocinador. Também pode criar atividades, mas isto dependerá de qual perfil o recurso possuirá.
Central de Recursos
Escuto falar muito sobre pool de recursos, e caso queira dimensionar onde e quando o recurso está alocado, poderá utilizar esta facilidade muito poderosa. Quando a empresa possui uma estrutura projetizada, esta facilidade se torna um ganho extremamente importante, pois o controle dos recursos são otimamente dimensionados.
Relatórios de Status
A funcionalidade do relatório de status no Project Server é um grande recurso, onde se pode elaborar as perguntas referente aos projetos e aguardar o retorno dos recursos. Ex:
Principais Realizações
Objetivos do Próximo Período
Questões Mais Graves
Dificuldade de aprovação
Este recurso é muito utilizado quando o Gerente de Projetos não possui acesso direto à Equipe do Projeto (equipe virtual), neste caso, poderá obter todas as informações oficiais (registradas no Project Server) antes das reuniões.
Relatório / Análise de Dados
Os relatórios oferecidos pelo Project Server são ótimos para o controle do projeto, pois a tecnologia de cubo do SQL permite que todas as informações do projeto sejam cruzadas e customizadas para a necessidade dos Executivos, Gerente de Projetos e sua equipe.
Aprovações
É de responsabilidade do gerente de projetos aprovar ou rejeitar qualquer mudança que ocorre no projeto, sendo assim, esta funcionalidade permite que o gerente de projetos obtenha controle sobre seu projeto.

Conclusão

A Solução do Microsoft Enterprise Project Management (EPM) é utilizada para Gerenciamento e Portfólio de Projetos, por sua facilidade de interação com outros aplicativos como a SharePoint como ambiente de colaboração e Project Professional com o objetivo de criar o cronograma para ser hospedado no Project Server.
O processo de implantação pode ser lento por diversos motivos, mas o mais conhecido é a falta de comprometimento dos Executivos e alta Gerencia, tanto por disputas políticas quanto por não terem a oportunidade de conhecerem a importância do Gerenciamento de Projetos ou mesmo por não conhecerem as metodologias de Gerenciamento de Projetos.

O planejamento para implantar o Project Server requer muita dedicação de diversas pessoas, e o treinamento é essencial para que os usuários se sintam confortáveis em utilizar esta ferramenta, sendo assim, caso sua Empresa pretenda utilizar o Project Server, compartilhe estas informações para confirmar se realmente sua Empresa está preparada para trabalhar com o Project Server.

Sergio Torres, PMP

10jun, 2013

Primeiro Cronograma

Criar um cronograma no Microsoft Project 2007

Ultimamente apareceram diversos programas para Gerenciamento de Projetos como o DotProject, GanttProject, TaskJuggler, Primavera, Project – open, Teamwork, TaskFreak, Basecamp, Trac, ActiveCollab, PHProjekt, WBS Chart Pro, JCVGantt, OpenWorkbench e o Microsoft Project Server, porém o Microsoft Project continua sendo o programa mais utilizado para o planejamento, controle e monitoramento de cronogramas e custos de projetos.

Os cronogramas criados no Microsoft Project oferecem opções de representar graficamente os dados do projeto, tanto pelo modo nativo quanto por aplicações de terceiros.
Os relatórios aprimorados no Project 2007 podem ser apresentados pelo Microsoft Excel versões 2003 e 2007 e Microsoft Visio versão 2007.

Para criar um cronograma, é necessário seguir estas etapas.

1º Denifir as atividades
Sugiro que estabeleça primeiro as atividades macro e então, decompõe tais atividades para um nível que possa gerenciar.

2º Sequenciar as atividades
Existem quatro opções de sequenciamento (término-início, início-início, término-término, início-término), o padrão do Microsoft Project é término-início.

3º Atribuir os Recursos as atividades
Crie os recursos na barra de modos “Planilha de Recursos” e atribua os recursos às atividades.

4º Definir a duração das atividades
Após atribuir os recursos (Trainne, Junior, Pleno ou Sênior), se tornará fácil o processo para definir a duração das atividades. Lembrando que os Recursos deverão fornecer as durações estimadas como também a aprovação das atividades a eles atribuídas.

5º Adicionar o campo “% concluída”
Para adicionar este campo, você deverá clicar no menu “inserir”, escolher o item “coluna!

{gallery}artigoproj2007{/gallery}
Sabemos que existem diversas etapas para concluir um cronograma, mas estes passos iniciais servem para despertar o interesse em aprofundar nesta ferramenta tão importante para quem trabalha com Gerenciamento de Projetos.

Sergio Torres, PMP
Mantenedor do Portal Projeto Diário
Email: [email protected]
Diretor e Instrutor do Projeto Diário Treinamentos
www.projetodiario.adm.br
Tel: (11) 5087-8943 / Fax: (11) 5087-8810
www.linkedin.com/in/sergioastorres
www.twitter.com/sergioastorres
Skype: sergioastorres
certificações: PMP, Prince2, COBIT, ITIL, SQMF, MCT, MCP, MCSA, MCSE e MCTS e MCITP.

6jun, 2013

Escritório de Projetos: Modalidades e responsabilidades

Com a profissionalização da área de gerenciamento de projetos nas organizações no Brasil, cada vez mais, os Escritórios de Projetos se fortalecem e passam a ser estruturas ativas no dia a dia das corporações. Desta forma, o Escritório de Projetos, também conhecido por PMO (Project Management Office) passa a assumir novas responsabilidades nos processos de seleção, de execução e dos resultados obtidos dos projetos; ademais, novos papéis surgem, como o Resource Manager (Gerente de Recursos) e o próprio Project Management Officer, que representa o profissional com autoridade máxima no Escritório de Projetos da organização.

O PMBOK (Project Management Body of Knowledge), reconhecidamente em nível mundial como o conjunto das melhores práticas na área de gerenciamento de projetos, publicado pelo PMI (Project Management Institute) apresenta o Escritório de Projetos como tendo a função primária de dar suporte aos Gerentes de Projetos que pode incluir, mas não se limitando a: gerenciar os recursos, compartilhando-os por todos os projetos, incluindo a realização de coaching dos profissionais, orientação de carreira e treinamento; identificar e desenvolver metodologias, divulgar best practices e padrões na área de gerenciamento de projetos; desenvolver políticas, procedimentos, formulários e documentações compartilhadas para a área de gerência de projetos; monitorar e auditar a aplicação de políticas, o uso de procedimentos e formulários definidos como padrões na organização; e também, coordenar a comunicação entre os projetos.

Um Escritório de Projetos deve ter sua personalidade na organização, pois pode ter abrangência e autonomia distintas, pois pode atuar como um Centro de Suporte a Projetos, Centro de Gerenciamento de Projetos ou Centro de Excelência.
Na primeira alternativa, como Centro de Suporte a Projetos, o PMO tem um papel consultivo e de apoio aos Gerentes de Projetos em suas dificuldades rotineiras.
Na segunda opção, como Centro de Gerenciamento de Projetos, tem sua responsabilidade ampliada, pois é o órgão responsável pela execução dos projetos, resultados, alocação de profissionais, garantindo a utilização correta das metodologias, ferramentas e procedimentos definidos.

Finalmente, se o PMO atua como Centro de Excelência, ou seja, se participa como Knowledge Management, deve ter uma abordagem voltada à busca de melhores práticas internas e de mercado na área de gerenciamento de projetos, definição de indicadores de desempenho, monitoração do progresso dos projetos, captura, armazenamento e divulgação das lessons learned (lições aprendidas) em projetos, etc.

O que se pode concluir é que o PMO também tem seu nível de maturidade. Aparentemente, a atuação como Centro de Suporte a Projetos ou Centro de Gerenciamento de Projetos pareça uma decisão gerencial, na realidade, trata-se de uma definição estratégica que atribui força, poder e responsabilidade ao Escritório de Projetos. Por isso, quanto mais amadurecida e mais voltada à estrutura projetizada estiver a organização, mais próxima da atuação como Centro de Excelência estará o seu Escritório de Projetos.

5jun, 2013

As estruturas organizacionais – descubra qual você trabalha!

Cada organização possui um estilo e cultura próprios que influenciam o modo como o trabalho de projeto é conduzido. Assim como os projetos são únicos, as organizações em que são executados também são.

O segredo para identificar o tipo de organização em que você trabalha é avaliar quanta autoridade a alta diretoria pretende delegar ao(s) gerente(s) de projeto. Embora a singularidade seja regra nas culturas empresariais, todas as organizações são estruturadas segundo uma destas três modalidades: funcional, projetizada ou matricial.

É útil conhecer e entender a estrutura organizacional e a cultura da entidade em que você trabalha.

O nível de autoridade de que o gerente de projeto vai usufruir é determinado pela estrutura organizacional. Por exemplo, um gerente de projeto dentro de uma organização funcional tem pouca ou nenhuma autoridade oficial. É possível que ele nem seja chamado de gerente de projeto, mas sim de líder, coordenador ou até de executor de projeto.

Vamos conhecer essas três modalidades de estrutura organizacional:

Organizações funcionais

É o tipo mais comum de organização e provavelmente o estilo mais antigo. A organização funcional é centrada em especialização e agrupada por função, razão pela qual são chamadas de organizações funcionais. Por exemplo, ela é organizada por setor, ou seja, setor de RH, setor de Finanças, marketing e etc. O trabalho nesses departamentos é especializado e exige pessoas com conjunto de habilidades e experiências nessas funções especializadas para realizar tarefas específicas do departamento.

Veja o organograma:

Organizações projetizadas

As organizações projetizadas são praticamente o oposto das organizações funcionais. O enfoque desse tipo de organização é o próprio projeto. A idéia que respalda uma organização projetizada é cultivar lealdade ao projeto, não a um gerente funcional.

Veja o organograma:

Nas organizações estruturadas exclusivamente por projetos, os recursos organizacionais são dedicados aos projetos e suas metas. Quase sempre, os gerentes de projeto têm total autoridade sobre o projeto e são subordinados direto da Diretoria, sem intermediários.

Organizações matriciais

As organizações matriciais surgiram para minimizar as diferenças entre os pontos fortes e fracos das organizações funcionais e das organizações projetizadas e para melhor explorá-los. A idéia é obter o melhor dos dois mundos, combinando-os em um só. Os objetivos do projeto são atendidos, técnicas eficientes de gerenciamento de projetos são aplicadas, ao mesmo tempo que também se mantém a estrutura hierárquica da organização.

Os funcionários de uma organização matricial se reportam ao gerente funcional e a, no mínimo, um gerente de projeto. Eles podem ser subordinados a vários gerentes de projetos, caso trabalhem em vários projetos simultâneos. O gerente funcional responde por incumbências administrativas e aloca funcionários para os projetos. Ele também monitora o trabalho de seus funcionários nos diversos projetos.

Hoje em dia, a maioria das organizações usa alguma combinação das estruturas organizacionais descrita acima. É raro uma organização ser estritamente funcional ou unicamente projetizada. Por exemplo, estruturas que giram em torno de projetos podem coexistir dentro de organizações funcionais. No caso de um projeto crítico e mais elaborado, a organização funcional pode designar uma equipe especial para dedicar-se a ele com exclusividade. O grupo é estruturado fora dos limites da organização funcional, e seu gerente detém autoridade máxima pelo projeto. Essa é uma abordagem de gerenciamento viável, que assegura a comunicação franca entre o gerente de projeto e os membros da equipe.

As organizações são únicas, assim como os projetos por elas empreendidos. Conhecer a estrutura organizacional ajudará o gerente de projeto no que diz respeito às influências culturais e vias de comunicação nela existentes, facilitando-lhe a obtenção de colaboração e a conclusão do projeto com êxito.

Bibliografia
Kim Heldman, PMP (2009). Gerência de Projetos Guia para o exame oficial do PMI. Rio de Janeiro: Elsevier.

4jun, 2013

Diferenciando Programas de Projetos

Um equívoco comum cometido pelos Escritórios de Gerenciamento de Projetos é conceber um Programa como Projeto ou vice e versa.

Em um primeiro momento esse tema parece soar sem importância, como se fosse apenas mais uma definição teórica e puramente conceitual, mas é a base para o fracasso real de inúmeros Projetos.

No Brasil e, principalmente, no setor corporativo privado, Projetos são erroneamente definidos como Programas apenas por serem grandes. Mas tamanho é simplesmente a consequência, e não o motivo para um Programa existir.

Outras justificativas usadas para transformar conjuntos de Projetos em Programa são o aproveitamento da dinâmica comum de vários recursos e a existência de inúmeras frentes de trabalho com mais de um time. Realmente Programas possuem essas características, mas apenas como consequência de um fator maior: a concepção de uma idéia geradora de um benefício estratégico, dando origem a um conjunto de iniciativas independentes responsáveis por concretizar o benefício idealizado.

Um Programa, antes de se tornar um conjunto de projetos, nasce como uma idéia estratégica geradora de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco ou dezenas de Projetos independentes. No momento de concepção do Programa, não sabemos ao certo o que deve ser feito para atingir o benefício idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas independentes gerará um benefício estratégico e único. E é comum um Programa, em plena execução, ainda gerar novos Projetos com o intuito de consolidar o benefício estratégico definido anteriormente.

Por sua vez, Projeto é um esforço pontual, menos abstrato. Por mais que um Projeto em sua fase de iniciação possua indefinição de escopo, tempo e custo, sempre temos em mente o principal entregável. Sabemos o “o que”. Apenas não sabemos ainda o “como”. E nesse contexto, para diferenciar um Projeto de um Programa, não importa o tempo, o custo e nem a quantidade ou interação entre os recursos.

Parafraseando o PMBoK (Project Management Body of Knowledge), do PMI (Project Management Institute), Projeto é um empreendimento temporário, com recursos limitados, que gera um resultado, produto ou serviço único. Já Programa é um conjunto de Projetos independentes que estão unidos e associados estrategicamente para geração de um benefício. Em um Programa, obviamente cada projeto possui um benefício próprio, afinal são independentes. Mas o benefício gerado pelo Programa é diferente dos benefícios individuais de cada Projeto. E esse benefício do Programa é geralmente pensado primeiramente e estrategicamente antes de ser criado o conjunto de Projetos.

Como exemplo, podemos citar o Programa de Aceleração do Crescimento (PAC) do Governo Federal. O Programa possui como objetivo construir infraestrutura logística e energética para sustentar o crescimento do País. O objetivo de um Programa sempre terá a característica de ser abstrato, pois na concepção da idéia só há a expectativa do benefício e não do objeto entregável. Não sabemos exatamente o que terá que ser feito para que o benefício seja obtido, tampouco como.

O Governo Federal dividiu o PAC em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.

Cada um desses Subprogramas possui vários Projetos. Por exemplo, o Subprograma Cidade Melhor possui o Projeto Construção Estação de Tratamento de Esgoto na Baixada Santista, o Projeto de Construção de Drenagem Urbana na Baixada Fluminense, entre outros. E há também os Projetos internos do Programa que não são expostos à população, como Projetos de marketing para promover o Programa em rádio, TV e Internet, Projetos de Desenvolvimento de Sistemas de Informação do Governo etc.

Outra característica dos Programas é a existência das Frentes de Trabalho. Em tradução livre do The Standard for Program Management do PMI, Programas incluem elementos de trabalho não contidos em nenhum de seus Projetos. Esses elementos são as Frentes de Trabalho, que atravessam os Projetos, não necessariamente todos, apoiando a integração necessária para o benefício único do Programa. Como exemplo, a auditoria interna poderia ser uma Frente de Trabalho do PAC. As ações de auditoria atravessariam os Projetos gerando o benefício de integridade do Programa como um todo. Mas oficialmente o PAC possui duas Frentes de Trabalho: Medidas Institucionais e econômicas e a outra é Desenvolvimento Econômico Social.

A construção de uma usina hidrelétrica, por exemplo, se idealizada unitariamente, é um Projeto. Mesmo que leve 10 anos para ser construída e mobilize bilhões de reais, continuaria sendo um Projeto, e não um Programa, pois o que foi idealizado é o produto de forma direta.

Essa usina poderia estar dentro do Programa de Aceleração do Crescimento, e seria completamente normal caso a usina não tivesse sido idealizada no momento da concepção do Programa, pois se pensou no benefício da Aceleração do Crescimento no Brasil, e não em todas as entregas palpáveis que concretizariam esse benefício.

Programas geralmente possuem fases futuras totalmente abstratas em escopo, tempo e custo, muito mais abstratas que as fases futuras de um Projeto. De maneira rotineira, Programas são subdivididos em fases ou subprogramas. A primeira fase constantemente possui projetos visualizados com mais clareza ou já em execução. E a as demais com a visualização apenas da percepção do benefício desejado.

Após toda essa exposição conceitual, ainda perdura a dúvida: qual o problema em confundir Projeto com Programa ou vice e versa?

Conceber e executar um Projeto como Programa não é tão grave, mas certamente criará na corporação uma imagem errada do que é Programa e a sensação de que gerenciar Programa é o mesmo que gerenciar Projeto. E caso a corporação comece a implementar o conceito de Programa, terá dificuldade em difundir o conceito correto.

Porém, será catastrófico executar um Projeto quando na verdade for um Programa. O “Projeto” sofrerá aumento de escopo e prazo constantemente e a corporação não entenderá o motivo, mas ocorre que o peso de uma idéia estratégica, que é abstrata, foi delineado para ser entregue em um único “Projeto”, que possui um molde pontual e bem mais objetivo que a fase inicial de um Programa. O titulado “Projeto” nesse caso, terá inúmeras fases e mais cedo ou mais tarde essas serão tão independentes uma das outras que possuirão entregas totalmente diferentes, auto-suficientes e com objetivos próprios. Novos entregáveis começarão a ser criados no decorrer do ciclo de vida e não serão bem aceitos pela corporação, pois serão concebidos como se fossem incremento de escopo (scope creep) e causadores de atraso, quando na verdade são novos Projetos, independentes, e que apenas agora se visualizou a necessidade estratégica de criá-los e assim solidificar cada vez mais a expectativa abstrata inicial. Essa sucessão de desastres costuma ocorrer quando se faz a gestão de um Projeto sendo na verdade um Programa.

4jun, 2013

Os 42 passos do PMBoK. Quão flexíveis eles são?

Como sempre digo, meu objetivo ao escrever é sempre avaliar se as técnicas, ferramentas e metodologias são aplicáveis, adaptáveis ou flexíveis. Em geral, minha conclusão é que: Como metodologia é composta por um conjunto de técnicas, o gerente de projetos ou o PMO a desenvolve sempre de forma aplicável (Premissa, nem sempre verdadeira, mas procuro partir deste princípio).

O PMBoK (Project Management Body of Knowledge) coloca 42 processos (Já atualizado conforme a quarta edição, na terceira eram 44) dentro das 9 áreas de conhecimento espalhados entre iniciação, planejamento, execução, monitoração e controle e encerramento. Mas temos que utilizar todos obrigatoriamente? Bom, respondo o que para a maioria é o óbvio: Não! O que o PMI, através do PMBoK nos mostra, são as melhores práticas, ou seja, o que funciona na maioria das vezes, na maioria dos projetos. Uma das funções importantes do Gerente de Projetos é saber avaliar onde cada coisa deve ou não ser utilizada.

Embora gerenciar projetos não seja uma ciência exata, tampouco uma receita de bolo, de maneira rápida, tentarei resumir como escolher o que aplicar (apenas uma sugestão. É a forma como eu aplico, cada G.P. terá a sua).

A quantidade de processos aplicáveis, em geral, varia de acordo com o porte do projeto. Em projetos grandes, com maior complexidade e integração entre várias disciplinas ou pessoas, aplicamos todos eles, porém, para projetos pequenos, meu roteiro é o seguinte:

– Verifique o quanto de papel sem necessidade esses processos irão criar! Lembre-se que o gerenciamento é para facilitar e manter o projeto no rumo, não para burocratizar;

– Pergunte para que eu preciso de tal processo, ou de tal saída do processo. Ela me será útil, ou será uma entrada obrigatória para processos importantes?

– Eu possuo dados, estrutura ou condições de alimentar o processo?! Um dos grandes problemas que vejo é o fato de criarmos formulários que depois não serão atualizados no andamento do projeto. Serão preenchidos ao final, apenas por mera formalidade, por tanto, perde a atulidade;

– Posso elaborar sistemas simples de planejamento, execução e controle? Não se iluda de que o bom gerenciamento necessita de ferramentas e métodos complexos, quanto mais simples melhor! As informações a serem monitoradas, assim como as métricas criadas devem me reportar algo importanta, monitorar apenas por monitorar de nada serve;

Lembre-se o custo do gerenciamento não deve exceder o do projeto, gerentes estão presentes para suportar o projeto, e não o projeto para suportar o emprego dos gerentes! Em suma, utilize o mínimo necessário, cuidado apenas para não reduzir demais e ficar órfão da falta de informação! Gerencie de maneira prática e rápida, preocupe-se com as informações importantes para a tomada correta de decisões. Tenho certeza que dessa forma seu projeto estará mais sob controle do que com planos mirabolantes. O importante é o bom senso!

4jun, 2013

Qual o nível de maturidade da sua empresa?

Não há mais o que falar sobre a necessidade de se gerenciar projetos, isso já é uma realidade, e certamente empresas que não o fazem estão fadadas ao fracasso. O que faz a diferença é a maturidade que a empresa tem em gerenciamento de projetos.

Segundo Harold Kerzner, um dos maiores (ou o maior) especialista em gerenciamento de projetos, maturidade em G.P. “É o desenvolvimento de sistemas e processos que são por natureza repetitivos e garantem uma alta probabilidade de que cada um deles seja um sucesso. Entretanto, processos e sistemas repetitivos não são, garantia de sucesso. Apenas aumentam a sua probabilidade”. Não preciso afirmar minha concordância sobre isso, já que venho sempre dizendo que gerenciar projetos não é adivinhar o futuro.

Existe uma infinidade de modelos de maturidade, OPM3, CMM, PMMM e etc, cada entidade especializada em gerenciamento de projetos possui seu modelo.

A maioria dos modelos divide maturidade em 5 níveis. Cada um usa seus nomes específicos. Tomei a liberdade, para facilitar a compreensão de todos e não dar preferência a um ou outro modelo de utilizar nomes genéricos para cada um dos níveis.

Nível 1) Ausência de gerenciamento formal, significa que não existe nenhum método ou procedimento formal para gerenciar projetos. Se sua empresa se encontra nesse nível, é melhor correr e mudar isso antes que o “barco afunde”.

Nível 2) A empresa possui algum tipo de gerenciamento, alguns métodos ou ferramentas, porém não integrados entre eles.

Nível 3) O gerenciamento já possui algum tipo de integração entre os processos, utiliza em alguns casos processos mais complexos e elaborados. Em geral, dão um foco maior em planejamento e controle.

Nível 4) O gerenciamento está completamente integrado, existe participação e suporte da alta administração, todos os objetivos, papéis e competências estão bem definidos, a fase de resistência a mudanças já se encerrou.

Nível 5) Gargalos já estão sendo identificados e existe além de processos de gerenciamento consistentes, uma política de melhoria contínua.

A adequação não precisa ser degrau por degrau, uma empresa pode ir do primeiro nível ao quinto, porém, em minha opinião, isso é completamente teórico, é muito mais eficaz trabalharmos as mudanças de curto e longo prazo separadamente.

Faça uma análise em sua empresa (e em você), e descubra qual seu nível de maturidade. Reconhecer o defeito é o primeiro passo para a mudança.

Category Archives: PROJETOS

Você esta pronto para utilizar o Project Server?

Primeiro Cronograma

Escritório de Projetos: Modalidades e responsabilidades

As estruturas organizacionais – descubra qual você trabalha!

Diferenciando Programas de Projetos

Os 42 passos do PMBoK. Quão flexíveis eles são?

Qual o nível de maturidade da sua empresa?