terça-feira, 28 de agosto de 2012

Framework de Gestão de Projetos - Análise Comparativa - PMBOK, PRINCE2, Agile, ISO, IPMA ICB


Framework de Gestão de Projetos - Análise Comparativa
 Artigo adaptado e sob  permissão do autor Ms. Rania Al-Maghraby, PMP (14/08/2012)


1. Introdução

A maioria dos frameworks e padrões de gestão de projetos são adaptáveis e podem ser customizados para um ambiente específico de projetos Pretendo explorar aqui as características mais importantes destes padrões e, sua aplicabilidade em um ambiente específico de projeto,  recomendo que você reflita ao término do texto como você pode utilizar-se de cada uma deles em seus projetos.


E agora ?
Qual caminho devo seguir ?


 2. PMBOK®– Projetct Management Body of Knowledge

Considerado o mais genérico e tradicional framework para gestão de projetos  atendendo quase todos os tipos de projetos. Foi inicialmente concebido e desenvolvido a partir da área de construção, é o mais popular; e adotado largamente por quase todos os gerentes de projetos. Por ser tão genérico o PMI®  (Project Management Institute) adotou extensões do PMBOK®  (como governo, por exemplo), objetivando atingir áreas específicas. O PMBOK®  tem evoluído ao longo dos anos graças à sábia contribuição de vários voluntários atingindo nível de maturidade cada vez maior. 
Uma de suas grandes características do PMBOK® se chama: Global Project Management, que trata da distribuição de equipe de projetos utilizando ferramentas de comunicação virtual. Além disto, o PMBOK® também é adequado em ambientes onde o envolvimento da equipe na tomada de decisão é importante, como: definição de tarefas, identificação de riscos, esforço de estimativas, etc. Embora no caso de pequenos projetos, como alguns projetos de Tecnologia de Informação, o PMBOK®  parece tão abrangente de extras que ser for literalmente aplicado seria burocrático e necessitaria de grande esforço para adaptação.

3. PRINCE2®

Uma característica única do PRINCE2®  OGC (ou cabinet office) é a separação entre o Gerente de Projeto e o papel do Gerente da Equipe, tornando-o mais atraente e adequado para gerentes de projeto que não possuem as habilidades sociais e interpessoais que seriam necessárias para liderar e gerenciar a equipe do projeto diretamente. 
Outro ponto importante à demonstrar se refere à estrutura do projeto PRINCE2® que é classificada em Fases de Gestão (Management Stages) e Etapas Técnicas (Technical Stage).
Isto ajuda nos casos em que os gerentes de projetos não têm experiência no campo técnico em que o projeto esta sendo gerenciado e,  com a adoção de Estágios Técnicos podemos envolver pessoal mais experiente tecnicamente (Gerente da Equipe). 
Há também outro item que no meu entendimento sofremos muito, que é a autoridade do projeto onde não é necessariamente assinalada na totalidade para o gerente de projetos, isto é,  o Comitê do Projeto é responsável por aprovar todos os planos de decisões no projeto e, cabe ao gerente de projetos a responsabilidade pelas atividades diárias do projeto. 
O Comitê do Projeto pode delegar autoridade para o gerente de projeto ou determinado papel no projeto para ele (ex. autoridade de mudança), este comitê possui também vários papéis e responsabilidades assinalados aos membros.
A gestão de projetos utilizando Prince2® é fortemente e orientado ao business case, isto é, sem ele o projeto nem é iniciado e, durante o ciclo de vida do projeto o resultado obtido em cada fase ou estágio é comparado contra o business case , para tomada de decisão do Comite de Projetos para avançar para as fases posteriores.
Ponto importante a ser acrescentado é que o Prince2® é facilmente conectado a metodologia de gerenciamento de portfólio de projetos porque o Comitê de Projeto utiliza-se de estágios para decidir e aprovar a continuidade do projeto, o que é tipicamente a proposta de revisão de portfólio de projetos.

4. Agile Project Management

É mais conhecido em Projetos de software de Tecnologia de Informação, é importante compartilhar a informação que acordo com a  Forrester Research® cerca de 35 % de profissionais de TI adotam processos ágeis.
Agile pode ser geralmente recomendado para Projetos onde o escopo é continuamente elaborado ou não muito bem definido, este método é mais recomendado para: coleta de informações com maior interação humana através de reuniões, forte ambiente de comunicação e, gestão transparente. Agile é mais bem utilizado em Projetos onde há muita mudança de requisitos devido a coleta de requerimentos e entregas do produto em fases para o cliente aliado ao fato que  o cliente quer ser envolvido de maneira participativa e continua. 
A metodologia se utiliza de rastreamento e forte gestão na condução do progresso das entregas de acordo com o valor já entregue e percebido pelo cliente, ou seja, planejamento baseado nas entregas e não em atividades.
No Agile, há menos autoridade para a função de gerente de projeto (Scrum Master), a equipe é auto-organizada e autogerida enfatizando a importância do fator humano para o sucesso do gerenciamento de projetos e incorporando de elementos sociais em atividades de gerenciamento de projetos.

5. IPMA's ICB®

O IPMA® (International Project Management Association) é um modelo de certificação baseado em competências. É versátil, coerente, sólido e cria desafios ao crescimento profissional do gerente de projetos. O modelo 4LC de Certificação por Competências é a melhor forma de verificar o aproveitamento nas dimensões do conhecimento tácito e explícito, por meio da verificação das Competências Técnica, Contextuais e Comportamentais, estes elementos integrados durante a gestão de projetos proporcionam ao gerente de projetos avaliarem situações específicas e decidir pelas ações apropriadas para o projeto. Ele é baseado em 4 níveis de certificação, iniciando-se no nível D, o mais baixo, até o mais alto que é o nível A.   Estes níveis variam de acordo com o conhecimento de gestão de projetos, passando por gerentes sênior, membros da equipe do projeto, subgerentes, gerentes de projeto, gerentes de programa e gestores de portfólio. Pode ser considerado um ponto controverso,  este modelo requerer um número mínimo de anos de experiência para certificar o candidato a certo nível (de D a A), enquanto que a combinação de competências pode não ser necessariamente equivalente ao número de anos de experiência, enquanto alguns profissionais podem estar em um nível de alta competência em outra área possuem pouca experiência e vice-versa. A forma como se apresenta os métodos de gerenciamento de projetos é contrário do apresentado em outras estruturas que incidem sobre os processos em fases de gestão de projetos, aqui se centra na pessoa que vai aplicar as atividades desses processos (o gerente de projeto) e que e como ele será executado. O IPMA® não recomenda ou inclui específicas metodologias, métodos e ferramentas porque ambos  podem ser definidos pela organização desta maneira o gerente de projetos deveria escolher o método apropriado para uma situação específica do projeto.
Assim, o uso mais adequado do ICB® é avaliar e adequar o nível do gerente de projetos e recursos para o tamanho do projeto e seu grau de complexidade, como uma garantia do melhor esforço para o sucesso do projeto. Isto é independente da indústria, e aplicável a quase todos os tipos de projeto.


6.2 ISO 21500 (Project Management - Guide to project Management)

A ISO tomou a iniciativa e criou um novo standard intitulado ISO21500: Guide to Project Management. Este padrão irá prover uma plataforma comum a qual irá se tornar ponto de referência para todos os profissionais de gerência de projetos e facilitar a transferência de conhecimento e harmonização dos princípios, vocabulário e processos nos padrões futuros, embora este padrão não tenha o propósito certificação, é apenas um documento de guia de gestão de projetos. Este novo padrão esta sendo desenvolvido pelo Comitê de Projetos PC236, com chair da British Standards Institute (BSI), e secretariado pela American National Standards Institute (ANSI). É formado por 3 grupos de trabalho:: WG1 (Terminology); WG2 (Processes); WG3 (Informative Guidance), este comitê foi fundado em 2007 cuja data original para ser completado era fevereiro de 2010, a data de publicação da norma ocorreu em Agosto de 2012.


BOM USO !
TWITTER: NELSONROSAMILHA
HTTP://WWW.FACEBOOK.COM/NELSONROSAMILHA (PÁGINA DE PROJETOS E EXCELÊNCIA OPERACIONAL)

terça-feira, 21 de agosto de 2012

O que é escopo ? "Vida de Inseto"


No filme "Vida de Inseto", testemunhamos a incansável luta de Flick, uma formiguinha, para melhorar a vida no formigueiro. Entre tantas confusões Flick recebe a missão de recrutar ajuda para repelir a ameaça dos gafanhotos. Então a formiguinha conhece os Guerreiros, uma trupe de péssimos artistas de circo, que, por uma das muitas confusões, pensa serem destemidos lutadores. 
Flick recruta a trupe imaginando que ela irá ajudá-lo a se livrar dos inimigos enquanto estes, por sua vez, acreditam que foram contratados para entreter os gafanhotos.
Não vou contar o restante para não estragar o divertimento do leitor. Mas gostaria de chamar a atenção para uma analogia que podemos fazer do filme. Neste caso temos alguém contratando uma empresa para entregar um determinado produto e, ao mesmo tempo, a empresa pensa que está sendo contratada para fornecer um produto diferente. Isto não acontece somente nos filmes, mas também em muitas situações envolvendo projetos, quando não existe o entendimento comum entre o cliente, quem está contratando e o fornecedor, que está sendo contratado.

Para buscar este entendimento é que devemos estabelecer o que denominamos de Escopo do Projeto. O escopo pode ser definido como o problema a ser resolvido com o projeto, é a linha que liga o ponto A ao ponto B, portanto deve ser definido, entendido e muito bem gerenciado. Na definição do escopo é que será determinado todo o trabalho a ser realizado em um projeto.
Em muitos casos os projetos iniciam sem a clareza necessária do que se deseja, ou então, somente com uma vaga idéia - ou desejos- do que se quer com o projeto. Esta falta de definição geralmente acarreta em retrabalhos com a finalidade de ajustar o escopo, atrasos no cronograma, falta de pessoas, custos estourados e, conseqüentemente, a insatisfação do cliente e até da própria equipe do projeto.Em projetos, temos duas definições de escopo:
- Escopo do produto - refere-se às características do produto ou serviço que se quer como resultado do projeto. Ele é explicitado por meio das especificações.
- Escopo do projeto - é todo o trabalho a ser realizado dentro do projeto para fornecer um produto ou serviço, de acordo com as especificações fornecidas.
Um outro ponto que deve ser levado em consideração quando falamos de especificações, e conseqüentemente do escopo do projeto, refere-se à natureza dos requisitos. 

Neste caso temos os requisitos explícitos, que estão na forma de registros, plantas, especificações, desenhos e outras formas documentadas. Estes requisitos são facilmente gerenciáveis. Também temos os requisitos implícitos, que são os que causam toda a confusão e problemas. Por exemplo, você pede para o pedreiro para construir um banheiro, entrega a ele uma planta, feita por você mesmo (afinal o engenheiro custa muito caro). Ele executa o que foi desenhado e no final, quando você vai conferir a obra, está tudo bem acabado, os revestimentos cerâmicos estão bem sentados e alinhados, porém só tem um "probleminha": o ralo não foi instalado. Você então parte para cima do pedreiro:
- Onde já se viu um banheiro sem ralo, é óbvio que você tinha que colocar o ralo!
- É verdade seu "dotôr", eu também nunca vi banheiro sem ralo, mas como o senhor não colocou no desenho, eu pensei que estava fora do escopo. Mas se o senhor quiser, eu quebro tudo de novo, coloco o ralo e lhe dou um desconto neste serviço adicional.

Como vemos em projetos o óbvio não é tão óbvio assim. Podemos até mesmo utilizar uma máxima do Direito: "O que não está nos autos não está na vida". Assim também acontece nos projetos, o escopo do produto deve prever todas as funcionalidades esperadas e o do projeto detalhará todo o trabalho a ser executado para que o produto do projeto seja entregue de acordo com o especificado.
A preocupação maior de um gerente de projetos é garantir que o escopo estabelecido seja cumprido, mesmo que sofra alterações, afinal de contas vivemos em mundo em que as mudanças acontecem cada vez mais rápidas e os projetos, ao longo de sua execução, devem se adequar às mudanças nos mercados e até mesmo às novas expectativas.
Para se ter sucesso no gerenciamento do escopo é necessário um bom gerenciamento de mudanças. Por mudanças entendemos como qualquer alteração ocorrida após a aprovação do escopo inicial. Ela geralmente envolve alterações nos custos, prazos, qualidade ou em outros pontos do projeto. Assim, no caso do banheiro acima citado, imagine que, pelo escopo inicial, o teto deveria ser em azul. Depois da pintura finalizada, você não gostou da cor e solicita que a mesma seja mudada para verde.
- Tudo bem "dotôr" - responde o pintor - só que esta alteração do escopo vai custar mais caro e levarei mais tempo para terminar a obra.
- É... pensando melhor o azul combina mais com meus olhos

BOM USO !
TWITTER: NELSONROSAMILHA
HTTP://WWW.FACEBOOK.COM/NELSONROSAMILHA (PÁGINA DE PROJETOS E EXCELÊNCIA OPERACIONAL)



quarta-feira, 15 de agosto de 2012

Recomendações para ser um gerente de projetos quando voce não é um Gerente de Projetos

Você é bom no que faz, conhece: marketing, finanças, é ótimo comunicador, contribui com equipe e, até mesmo no processo de vendas. Tem capacidade de manter a equipe motivada, conhece bem a área técnica em que atua, cria e distribui os relatórios de status com qualidade e no prazo, é bom ouvinte, e gerencia as atividades como ninguém! 

Seus colegas de mesmo nível hierárquico acham voce um ótimo gerente de projetos. Há um único problema, você não é gerente de projetos! Esta certo.. Não é o seu trabalho.  Você  apenas atendeu um chamado do CEO da empresa para ajuda-lo neste projeto devido ao seu conhecimento técnico.

Você não sabe nada de EAP, datas marco, entregáveis, pacotes de trabalho, software de controle de projetos, crash, etc...Mas você possuí aquela habilidade que poucos tem: manter as pessoas organizadas e ter o trabalho entregue na hora certa.


Se você gosta deste tipo de trabalho e não se importa em trabalhar um pouco mais e, já esta considerando em fazer uma transição para a posição de gerente de projetos mesmo não sendo um, segue 6 recomendações:


1. Receba feedback de todos

Uma das primeiras lições aprendidas pelos gerentes de projeto logo no começo é que eles não pedem feedback do projeto até que o projeto entre em tempos difíceis. 

Durante este período você irá ouvir dos interessados no projeto:

- "Eu sabia que havia um problema, mas nunca tive a oportunidade de dizer a ele"
- "Esta é a primeira vez que ouço isto", estas frases virão seguidas dos famosos ele não quer ajudar a resolver o problema..

Tenha certeza que todos tenham suas preocupações endereçadas, mesmo daqueles que dizem que não há problema, explore com mais profundidade, voce pode ficar surpreso.


2. Monitore utilizando uma planilha de cálculo 

Se voce não é especialista em MS Project, Primavera, etc...não se desespere, utilize uma planilha de cálculo  (provavelmente alguns de meus leitores nunca mais voltem ao blog por ter escrito isto...). Não estou dizendo para utilizar planilha perpetuamente. Embora a planilha é uma ótima ferramenta para que você rapidamente atualize as atividades, donos, datas de entrega e riscos associados. Ela pode ser utilizada como base para um relatório de status de projeto e, posteriormente como origem para carregar um sistema de gestão de projetos.

3. Crie e trabalhe na sua lista de to-dos  

Agora que você recebeu feedback de todos, tem tudinho gravado na sua planilha (ou similar), começe  a fazer sua diária de to-dos. Isto vai ajudar a manter a equipe e o projeto nos trilhos.


4. Utilize o clássico relatório em quatro blocos

É um relatório básico que te ajuda a ter a visão geral do passado, "what´s next” , o que pode dar errado e uma visão geral do projeto, veja um exemplo:





5. Documente mudanças 

Esta é uma área onde os gerentes de projetos menos experientes não percebem quão crítico é, até que ele sofra uma ou duas vezes... Documentar mudanças é imprescindível e não importa se é grande ou muito pequena, apenas registre o que é, quem, onde e quando esta mudança ocorrerá. 
Este registro vai te ajudar a eliminar mal entendidos que podem surgir dos interessados no projeto. 

6. Reconheça e celebre o sucesso 

Dê crédito a quem é de direito. Deixe que todos saibam em todos os níveis organizacionais e se possível premie seus colegas que obtiveram sucesso.

BOM USO !
TWITTER: NELSONROSAMILHA
HTTP://WWW.FACEBOOK.COM/NELSONROSAMILHA (PÁGINA DE PROJETOS E EXCELÊNCIA OPERACIONAL)


quarta-feira, 8 de agosto de 2012

Coisas que voce não deveria fazer quando gerencia um projeto

Coisas que você não deveria fazer quando gerencia um projeto

Como gerentes de projetos, fomos treinados (quando muito...) a sermos otimistas,  olharmos a luz no final do túnel...enquanto há vida há esperança, focarmos no que pode e deve ser feito ao invés de não pode ou não dá...Embora, a medida que progredimos na carreira você irá perceber que as coisas não são bem assim...Bem, aqui vai algumas dicas do que você (inclusive este autor) não deveria fazer quando gerencia projetos. 

1. Nunca assuma a primeira resposta que você recebe como fato  ou verdade

Gerentes de projeto estão sempre em negociações permanentes e incessantes. Todos os seus dias são compostos de datas, custos, entregas e prazos. 
Com isto você sente-se "obrigado" a responder com rapidez, pronto, primeiro erro... Ou ainda pior assumir a primeira resposta como verdade.

Nunca assuma que a primeira resposta que você recebe como fato seja a verdadeira, se, esta resposta  não atende às suas necessidades. 

Em vez disso, encare isto como ponto de partida para uma  negociação/discussão. Todos nós já estivemos na situação em que um recurso vai estima um número ridículo de horas para executar uma tarefa. E, quando você se aprofunda nos detalhes, e faz as perguntas certas... Você descobre rapidamente que a tarefa pode ser feita em uma fração do tempo original citado.
Pode parecer forte, mas recursos executam o trabalho ao longo do período de tempo possível e disponível, isto é, estimado por eles (é natural)...

Gerentes de projeto devem ser treinados para reconhecer quando isso esta acontecendo e rapidamente por fim a esse comportamento, esta mudança cultural tem que ocorrer, polêmico não ?

2. Bom senso

É fácil você se perder na metodologia de gestão de projetos, atualizando checklists, seguindo processos e procedimentos enquanto o seu projeto sai do controle.... Claro que metodologia deve ser utilizada, mas use o bom senso! Sua função é tomar decisões sensatas e utilizar de criatividade e inovação para fazer com que as atividades sejam executadas e o projeto entregue.

Pode parecer confuso você quebrar o processo ou modificar os procedimentos, mas lembre-se que você precisa entregar um projeto que traga valor para a organização e não apenas um monte de papel!

3. Gerencie seu stress pessoal e evite respostas emotivas

Gerenciamento de Projetos é difícil e pode ser estressante. O trabalho pode parecer difícil e inconcebível. Mas é o seu papel enfrentar este caos de maneira imperturbável. Lembre-se você esta a frente de sua equipe e, o peso da política, prioridades, indecisão e críticas recaem sobre você. É necessário proteger sua equipe para que possa segui-lo com segurança.  Não torne as coisas piores. 

A equipe precisa saber que você tem o controle da situação

4. Não faça o trabalho de sua equipe !

Imagine a cena, sexta-feira , cinco e meia da tarde....
Voce gerente de projetos esta verificando o último pacote de requisitos (já que voce tem experiencia nisto, aproveitou para verificar..) que será entregue ao seu cliente na segunda-feira de manhã, e percebe que que há erros e voce mesmo pode corrigir !

Voce reluta e decide não chamar seu funcionário de volta para fazer a correção, afinal de contas somos uma equipe e voce precisa demonstrar que pode ajuda-los. Não estou falando sobre voce ser parte da equipe ou colaborar com eles... temos um problema causado ppor voce, todos devem respeitar a função dos colegas , sua função não é ser Analista de Requisitos e sim Gerente de Projetos. 

Mantenha isto claro para todos, papeis e responsabilidades e, chame-o de volta.

5. Não escale muito cedo ....ou muito tarde

Escalar é uma arte. Quando voce escala muito cedo as pessoas pensam que voce não consegue resolver nada e qualquer coisa voce pede ajuda...Se voce escala muito tarde, voce rapidamente perderá credibilidade e efetividade e, rapidamente sua carreira como Gerente de Projetos enfrentará problemas na empresa.. Não há uma ciência para escalação de problemas, aprender com o passado ajuda. Recomendo que você sempre procure identificar áreas que potencialmente podem "incinerar" seu projeto e impactar a organização;  mantenha forte foco nestas áreas e, tenha certeza que voce entenda o que é importante e necessita de atenção extra.

6. Não se atole nos detalhes

Vamos enfrentar isto...Gerente de Projetos adora detalhes. Nós gostamos de saber como as coisas funcionam, gostamos de entender o que faz com que as pessoas tomem as decisões em funçao dos detalhes tecnicos. Isto pode deixar voce sobrecarregado de trabalho e, como consequência...voce ja sabe....Tente ficar longe deste tipo de atividade o máximo que puder, isto é trabalho para seus colegas experts, seu trabalho é pavimentar a estrado do projeto.

7. Não declare vitória muito cedo

Voce pode ver a luz no final do tunel a medida que o projeto se encerra! Mas nunca assuma que voce chegou la ! Não se deixe cair na armadilha, finalize o projeto 100 %. A verdade é que voce pode não saber o que voce não sabe ! Problemas inesperados podem estar rondando..e voce precisa estar atento !  

Bom uso !
Twitter: nelsonrosamilha
http://www.facebook.com/nelsonrosamilha (página de projetos e excelência operacional)

sábado, 4 de agosto de 2012

Seis Sigma e Gestão de Projetos - Pmbok

Apresentação sobre a metodologia Seis Sigma e Gestão de Projetos - Pmbok:, material muito bom e
detalhado , vale a pena !

http://www.slideshare.net/rosamilha/relao-entre-seis-sigma-e-pmobok

BOM USO !

Nelson Rosamilha,PMP®,BB®,Prince 2 Practitioner®
rosamilha@gmail.com
Twitter: nelsonrosamilha
http://br.linkedin.com/in/rosamilhahttp://www.facebook.com/nelsonrosamilha (Página de Projetos e Excelência Operacional)