Domingo, 26 de Outubro de 2008

PROJETO - Portal Gestão de Projetos.NET para Março 2009

Pessoal,

A princípio este blog foi criado com o único objetivo de expor minhas idéias e pensamentos a respeito de governaça de ti, gestão de projetos e gestão de serviços de TI.

Felizmente o número de visitantes está aumentando gradativamente, estamos com uma boa posição no ranking do google e até alguns anunciantes, escolas e consultorias do segmento estão com interesse em divulgar banner de suas empresas neste blog.

Assim como em qualquer negócio, as boas oportunidades não podem ser deixadas de lado.

Este blog a partir de Março de 2009 se tornará um portal completo com notícias, artigos, podcasts, fóruns de discussão, livraria on-line e muito mais.

Este portal sem dúvida alguma tem como grande finalidade a divulgação de informação para a comunidade de gestão em geral e a participação dos membros será fundamental.

Convido aos interessados em serem colunistas do portal a me enviarem e-mail manifestando seu interesse.

O portal será algo nos moldes do conceituado imasters (www.imasters.com.br). Aconselho a darem uma visitada nele para terem uma idéia.

Os interessados em serem colunistas, enviem e-mail para contato@gestaodeprojetos.net informando os seguintes dados:

- Nome completo
- E-mail
- Grau de instrução
- Segmento que atua
- Assunto que gostaria de ser colunista (gestão de projetos, itil, sox, cobit e afins.)
- Certificações que possui
- Tempo de experiência
- Cargo atual
- Estado e Cidade

Aos selecionados também estarei solicitando o envio de uma fotografia de rosto para colocar no site afim de identificar os colunistas.

Apenas para esclarecimento, o dinheiro que o portal estará recebendo com a exibição de banners será destinado aos custos para manter o portal no ar, como hospedagem, domínio, sorteios de brindes e um programador freelancer para eventuais implementações.

Abraço!

Marcadores:

Integração entre governança de ti (COBIT), gestão de projetos (PMI) e gestão de ti (ITIL)












Clique na imagem para expandir a visualização


A um certo tempo venho percebendo a confusão que o pessoal de TI faz quando se fala em ITIL, COBIT, PMI, PRINCE 2 e afins. Essa sopa de letrinhas tem gerado confusão no meio do pessoal mais técnico, que não é muito familiarizado com gestão para TI. PMI é uma metodolodia? PMO é o nome do cargo do profissional? Coisas do gênero constumo ouvir.

Para ajudar o pessoal, vou passar um definição geral e não muito detalhada mas que poderá ajudá-los com essa "sopa".


COBIT:
O Cobit trata-se de um modelo de referência para gestão de TI. E ai já começa a confusão. Alguém poderia estar pensando neste momento: "mas, a ITIL não tem a mesma finalidade?". Definitivamente não. A camada de atuação de ambas não é a mesma.
Através das ferramentas do Cobit, o gestor de ti irá cuidar da TI para que ela atenda as espectativas de negócio da empresa.
Vou explicar através de um case pois o entendimento ficará mais simples.

Imagine um grande banco. Este banco pretende expandir seus negócios no Brasil. Irá abrir 57 novas agências até o final de 2009, e seu atendimento ao cliente que era somente no horário comercial, de segunda a sexta, agora passará a ser 24x7. Além disso, a diretoria sênior do banco já preve a abertura de mais 35 agências para o primeiro semestre de 2010.

Ok. Agora que a diretoria já decidiu seu plano de expansão, teremos que ter TI para que tudo isso funcione correto? Alguém já viu uma agência sem sistemas para controlar saque de dinheiro, depósitos, investimentos ou um sistema para o sac registrar os chamados? É, eu também nunca vi. Toda esta expansão sem TI simplesmente não aconteceria.

O diretor de TI que participava desta reunião de divulgação dos planos de expansão ficou atento a estes números. Após a apresentação do plano, o presidente nacional do banco, olhou para ele e disse "Fulano, em 4 semanas quero uma apresentação para a diretoria nos exibindo o que precisamos investir em TI para que nossa expansão ocorra sem problemas. Quero saber além da necessidade técnica, o orçamento e o retorno que termos sobre este investimento".

É nesta camada que o COBIT atua. O Cobit está mais próximo do negócio do que qualquer outra prática, framework, metodologia ou o que for. O Cobit auxilia a diretoria de TI a decidir e controlar os investimentos em TI, a gerar indicadores e a justificar o investimento. Utilizamos a Cobit para conseguir definir o que é preciso comprar, desenvolver ou alugar para que os objetivos de negócio sejam concretizados.

Em nosso case, o objetivo é a abertura das novas agências e o sac de 24x7.

Neste caso poderiamos exemplicar de forma extremente resumida que seria necessário:

- aquisição de 7500 computadores
- 7 servidores com arquitetura risc
- contratação se XPTO funcionários
- etc

Vamos dar mais um passo. Realizamos a apresentação para a diretoria, exibimos o que é preciso de TI para atender o objetivo do negócio, exibimos o orçamento, os riscos, as vantagens, o ROI etc e a diretoria aprovou o investimento. Fase 1 concluída.

Agora é hora de colocar esse plano em ação. Quem irá realizar a implantação, configuração dos 7500 computadores e dos 7 servidores? Sim a equipe de GESTÃO DE PROJETOS.

O orçamento de TI foi aprovado agora a "bola" passa da mão do pessoal de governança de TI (Cobit), para o pessoal de gestão de projetos (PMI, PRINCE2 etc).

O pessoal de gestão de projetos poderá utilizar as melhores práticas do PMI e com base nelas criar sua própria metodologia, utilizar uma metodologia padrão de mercado como a Prince2 ou outra de sua preferência.

Serão criados planos para gerir a qualidade do projeto, o escopo, o tempo, as comunicações etc, tudo visando que as 7500 máquinas sejam implantadas corretamente, assim como os servidores. O gerente de projeto irá acompanhar e coordenar a execução de atividade por atividade, como por exemplo:

- instalação de cpu
- instalação do monitor
- instalação do sistema operacional
- instalação do sistema bancário
- testes de conexão com o servidor
- etc

Ok. Projeto entregue e implantado com sucesso. Servidores rodando perfeitamente, agências operando e sac 24x7 a todo vapor.

Pois é, e agora, quem irá MANTER tudo isso? Opa, agora sim aparece a ITIL para gerir a TI. Agora que o projeto já está em operação, não é mais de responsabilidade do pessoal de projetos, mas sim do pessoal que cuida da infraestrutura de TI, do pessoal que trabalha com ITIL.
Através da ITIL a equipe de infraestrutura terá processos bem definidos para gerenciar estação por estação, para gerenciar os servidores, para gerencia a capacidade, ou seja, se o tamanho do disco rígido é adequado, se o tamanho do hd é adequado, para gerenciar a liberação de software, garantindo que só softwares originais e licenciados estejam em uso, acorda níveis de serviço (SLA), define os planos de continuidade do negócio, por exemplo, redundância de servidores para que, em caso de desastre, um seja acionado automaticamente caso o outro pare, dentre outros controles.

Para resumir o entendimento, basicamente falamos que:

- COBIT
Atua na definição que o negócio tem referente a TI para poder atingir suas metas.

- GESTÃO DE PROJETOS
Atua na concretização da necessidade de TI levantada pelo pessoal da governana de TI (COBIT).

- ITIL
Após a implantação do projeto, o ITIL tem o dever de manter a infraestrutura de TI operante, ou seja, cuida do dia-a-dia.

Algumas definições:

- PMI
Não é uma metodologia, não são as melhores práticas e nem é o nome de uma certificação.
PMI significa Project Management Institute, ou seja, Instituto de Gerenciamento de Projetos. Trata-se do instituto que com a ajuda de profissionais do mundo todo definiu as melhores práticas para se gerenciar projetos e as publicou no PMBOK.

- PMP
PMP trata-se da certificação para profissionais de gestão de projetos criada pelo PMI. Esta certificação garante que o profissional possui um nível aceitável de conhecimento em gerenciamento de projetos.

- PMO
PMO não é um cargo. PMO significa PROJECT MANAGEMENT OFFICE, ou seja, Escritório de Gerenciamento de Projetos.
Trata-se do departamento que coordena os projetos em execução na compania.

- PRINCE2
Prince2 é uma metodologia comercial para gestão de projetos. No Brasil não possuimos muitos adeptos, mas no exterior sim. De qualquer forma o padrão adotado mundiamente em grande escala são as melhores práticas do PMBOK e a partir delas cada empresa cria sua metodologia.

Até a próxima!

Marcadores: , , , , , , , , , , ,

INFORMATION WEEK para todas as camadas da pirâmide




A conceituada revista INFORMATION WEEK agora está disponível a todas as camadas da pirâmide hierárquica da TI.

A assinatura da revista é gratuita, porém, para ter o direito de receber a revista em casa é necessário preencher um formulário de avaliação, e normalmente os eleitos são no mínimo coordenadores de TI. Não adianta atacar pedras no pessoal da seleção. O foco da publicação é este mesmo. Coordenadores, gerentes e diretores de TI, o pessoal que decide, coordena e dá os rumos da TI dentro da empresa.

Porém, existem muitos como eu que visualizam o futuro de suas carreiras em uma dimensão mais próxima do negócio do que da parte técnica e temos que ficar pedindo emprestada a Information Week do chefe para ficarmos antenados no que está acontecendo de principal na dobradinha TIxNEGÓCIO.

Pois bem, a INFORMATION WEEK está disponibilizando gratuitamente em formato PDF as edições da REVISTA para todo e qualquer simples mortal, inclusive nós que ainda somos analistas de projetos, processos, requisitos, suporte, programação ou seja lá o que for e que tenha gestão como meta de futuro profissional.

Basta acessar www.informationweek.com.br e baixar seu exemplar.

Abraço!

Marcadores: , , ,

Terça-feira, 21 de Outubro de 2008

Você já ouviu falar em metodologia ágil?E em scrum?

Pois é pessoal, de tempos em tempos novas metodologias surgem no mercado, ou melhor, surgem muitas, porém poucas se consolidam e são adotadas pelos principais players do mercado de TI.

A SCRUM é uma das "novidades" que tem ganhado muita força no Brasil nos últimos 2 anos.

Veja abaixo uma descrição sucinta sobre a SCRUM:

Scrum é um método ágil para Gerenciamento de Projetos.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo "The New New Product Development Game" (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

Mesmo que o Scrum tenha sido idealizado para ser usado em gestão de projetos de desenvolvimento de software, ele também pode ser usado para gerenciar equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.

Características de Scrum

* Cada sprint é uma iteração que segue o ciclo PDCA e entrega um incremento de software pronto.
* Um backlog é um conjunto de requisitos, priorizado pelo Product Owner (cliente);
* Há entrega de um conjunto fixo de itens do backlog em uma série de iterações curtas ou sprints;
* Uma breve reunião diária ou scrum, onde cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting, já que os membros do time geralmente ficam em pé).
* Uma breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
* Uma retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas) mas atua como um firewall entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de "controle". Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de "receita de bolo" do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou Prince2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos.

Planejamento de sprint

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum Simplificado

Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível ("stealth"), usando os três passos:

* Agende uma demonstração do software com seu cliente em um mês a partir de agora;
* Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
* Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.

Algumas práticas de Scrum

* Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
* Entregas freqüentes e intermediárias de funcionalidades 100% desenvolvidas;
* Planos freqüentes de mitigação de riscos desenvolvidos pela equipe;
* Discussões diárias de status com a equipe;
* A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
o O que fiz desde ontem?
o O que estou planejando fazer até amanhã?
o Existe algo me impedindo de atingir minha meta?
* Transparência no planejamento e desenvolvimento;
* Reuniões freqüentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
* Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
* Locais e horas de trabalho devem ser energizadas, no sentido de que "trabalhar horas extras" não necessariamente significa "produzir mais".

Agendando discussões diárias

Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes estão focadas no trabalho e não em questões pessoais.

Scrum Solo

Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

Marcadores: , , , , , ,

Gerenciar projetos de websites é diferente

Por vezes deparei-me com GP´s que acreditavam ser impossível adotar as práticas do PMI para gerenciar projetos de websites. Estes acreditavam que os processos sugeridos pelo instituto eram muito burocráticos ao ponto de não se obter benefícios ao adotá-lo.

A verdade é que as boas práticas do PMI são adaptáveis a qualquer segmento e sem dúvida alguma, utilizada sem parcimônia em TI e Engenharia Civil.

Até certo ponto entendo a opinião destes profissionais. Até então gerenciar projetos de websites seguindo alguma metodologia, framework ou melhores práticas era coisa para poucas grandes agências. Nas pequenas a realidade normalmente sempre foi outra, ou seja, o trabalho se resumia a execução e nada de planejamento e ai já sabemos o final da história: retrabalho, retrabalho, erros, erros, retrabalho e por ai vai.

É possível sim definir uma metodologia para gerenciar projetos de websites baseada nas práticas divulgadas pelo PMI.

Projetos web em sua essência são muito mais dinâmicos que, por exemplo, projetos de implantação de software ERP, ou desenvolvimento de software. Realmente, o fluxo não pode ser tão burocrático pois o tipo de trabalho exige agilidade.

O controle integrado de mudanças precisa ser estruturado de tal forma que determinados tipos de alterações não dependam de um comitê. Por exemplo, subimos o website ao ar e o cliente solicita que a disposição dos textos seja alterada os alinhando à direita da tela.

Devem existir regras para que este tipo de revisão possa ser realizada sem a necessidade de passar por um comitê, ou por fluxos padrões de desenvolvimento de software.

Estou preparando uma metodologia baseada nas boas práticas do PMI para gestão de projetos de websites e estarei disponibilizando neste site ainda no primeiro semestre de 2009 com templates e tudo mais.

Aguardem.

Abraço!

Marcadores: ,

Domingo, 19 de Outubro de 2008

Gestão de projetos como ferramenta de apoio ao gerenciamento de serviços de TI

O gerenciamento de serviços de TI, dentre outras atividades como gerenciar incidentes, problemas e capacidade, também gerencia mudanças. Estas mudanças podem ser pequenas alterações como adição de pentes de memória em desktops da equipe de um callcenter ou pode ser a troca completa de todas CPUs mainframes de uma empresa.

Em casos de grandes mudanças onde exista um elevado risco ao negócio se algo der errado, sem dúvida alguma a gerência de serviços de TI pode e deve recorrer ao gerenciamento de projetos seja com equipe interna, ou com consultores externos.

O gerenciamento de mudanças não executa a mudança em si. Este processo na verdade coordena esse trabalho. A execução é realizada pela equipe de projetos.

Normalmente a gestão de projetos se relaciona com os principais frameworks de gerenciamento de TI e estarei procurando escrever sobre estes nos próximos posts.

Até mais!

Sexta-feira, 17 de Outubro de 2008

Devo contratar um profissional certificado ou com experiência?

Quando um departamento solicita ao RH de sua empresa a contratação de um novo gerente de projetos o que pesa mais? Certificação ou Experiência?

O estímulo para que eu escrevesse este post veio através de um anúncio que li no blog corporativo da Locaweb. No post o autor (um dos sócios) dizia que possuia uma vaga na empresa para engenheiro e que era restrita a profissionais recém formados pela USP, UNICAMP ou ITA.

Até onde o nome de uma instituição ou um certificado garante ao empregador que o profissional a ser contratado será a melhor opção?

Particularmente discordo desse pré-conceito e posso tomar minha pessoa como exemplo. Por ter que trabalhar desde cedo não tive tempo para fazer cursinho e entrar em alguma universidade federal ou estadual pois trabalhava e cursava o 2º grau técnico. Quando chegou a época de faculdade tive que optar por uma particular que não possui o mesmo prestígio que uma UNICAMP da vida mas que oferece tantas condições quanto para que eu fosse atrás de meus objetivos.

O problema das instituições particulares concentra-se no processo seletivo que na verdade não seleciona nada e com isso, muitas pessoas desinteressadas, que vão estudar por obrigação (por exemplo, pais que obrigam), acabam sendo aprovadas para entrar em algum curso. Como não possuem um mínimo de interesse, passam 8 ou 10 semestres sem aprender uma vírgula (ou quase isso) e se "formam", formação essa baseada em plágios e colas, mas realmente sem conteúdo. O empregador contrata esse cidadão, e após algum tempo de experiência percebe que não sabe nada. Por causa de uma dúzia de maças podres (normalmente escolhidos para fazer o ENEM infelizmente) todo o pomar leva a fama.

Opa, mas pera lá! No meio das maças podres existe muita gente interessada que procura aprender a cada dia mais e evoluir, como eu =) !

Pessoas esforçadas e dedicadas que suprem as deficiencias da universidade da seguinte forma: SUOR E DETERMINAÇÃO.

Meu estudo nunca se limitou ao conteúdo ministrado na universidade. SEMPRE complementei minha formação academica com cursos extracurrículares, autodidata (sites, artigos, fóruns, livros etc.). Passei (e ainda passo) muitas madrugadas lendo papers pela net, teses e afins.

Por essas e por outras não concordo com essa discriminação. Sou TÃO BOM PROFISSIONAL (ou melhor) que qualquer profissional graduado em federais e não iria admitir esse tipo de preconceito. Não faço parte dos desinteressados e não aceitaria ser rotulado como "menos inteligente" ou algo do tipo simplemente pelo fato ter estudado em uma instituição de menor prestígio pelo motivo já citado.

Voltando ao papo do GP.

Quando um profissional de RH contrata um novo colaborador, provavelmente tenderá a selecioná-lo pela "sopa de letrinhas" que constar em seu currículo até por se tratar de um profissional de humanas e que provavelmente não possuirá conhecimento técnico, ou possuirá um conhecimento bem superficial.

De fato isto é um erro, assim como limitar a seleção de um profissional a XPTO instituições.

Certificação é algo que se tornou "HOT" somente agora, quem dirá para gerenciamento de software. Que vaga exigia um profissional para gerenciar projetos de implantação de sistemas com certificação PMP a 8 anos atrás?

Na empresa que trabalho, existem dois GPs na faixa dos 46 anos, ambos sem certificação. Digo a vocês que tem muito PMP que não vale metade de um deles. A experiência, a "malandragem", o "feeling" desses dois caras não tem prova de $550 doletas que compre.

A experiência ainda é sim o quesito de avaliação mais importante, porém, ignorado por muitos profissionais de RH da atualidade.

Me digam qual certificação seria mais válida do que a experiência de mais de 20 anos em projetos de um profissional?

Pois é. Que o marketing e modismo das instituições e certificações do momento não sejam a barreira que impedirá que GRANDES E PRECIOSOS profissionais atuem pelo simples falto de não terem um papelzinho assinado por Harvard, FGV, PMI e afins.

Lembrem-se pessoal. Grandes empreendedores brasileiros nem 2º grau completo possuem. Existem homens e mulheres faturando milhões de dólares anuais e nunca pisaram dentro de um IBMEC, USP, ITA e afins.

Só para finalizar NÃO SOU CONTRA certificações e os cursos das grandes instuições, muito pelo contrário, corro constantemente atrás das certificações que tenho interesse. O "x" da questão é que tanto um profissional certificado quanto um não certificado devem ser chamados para seleção e ai, nos testes, na dinâmica sejam avaliadas as capacidades de cada um para que o MELHOR seja escolhido independente de seu histórico escolar ou certificações, mas sim pelo profissional que realmente é. E o melhor pode ser sim, o sem certificação, que se formou na Quilombo do Palmares, na Universidade Paulista, na Unifieo e por ai vai.

Não é a universidade que forma o profissional, quem forma o profissional é sua determinação, sua garra e sua vontade de crescer. Quem tem interesse irá suprir as deficiências encontradas de alguma forma alternativa. Lembrem-se dos empreendedores brasileiros. Tenho certeza que vão se lembrar de alguém que chegou lá sem ter nem colocado o pé dentro de uma universidade.

Certificações também não garantem bons profissionais. Elas servem de complemento para aqueles que são bons e de máscara para aqueles que são péssimos assim como uma gradução.

E você, profissional de RH, na hora de selecionar um candito ESCOLHA O MELHOR independente se tem 7 certificações ou nenhuma. Sua empresa lhe agradecerá.

Abraço!

Marcadores: ,

Terça-feira, 30 de Setembro de 2008

O novo exame PMP e a 4ª edição do PMBOK

Aproveite o momento e faça ainda este ano a sua preparação para a Certificação PMP®.

O novo PMBOK® será lançado em dezembro de 2008 e a prova mudará gradualmente até o início do 2º semestre de 2009.

Como será o processo de atualização do exame PMP em relação à 4ª edição do PMBOK, previsto para lançamento em dezembro deste ano?

Assim que for publicada a nova edição, todas as novas questões criadas pelo PMI para o exame que dizem respeito ao PMBOK serão alinhadas com a 4ª edição.

Como é prática do PMI há algum tempo, as novas questões são testadas em exames como parte das famosas 25 questões que NÃO pontuam para o resultado (mas que o candidato não sabe quais são), até que estatisticamente sejam aprovadas para inclusão na base de questões definitivamente. Desta forma, as novas questões vão substituindo as antigas até que no chamado “third quarter” ou 3º trimestre, não haverá mais questões referenciadas ao PMBOK 3ª edição, finalizando a transição. Desta forma, quanto mais você demorar a fazer seu exame, a partir de janeiro, mais você deve conhecer a 4ª edição do PMBOK.

Marcadores: ,

Em projetos é melhor utilizar poder ou exercer liderança?












Para começar este post gostaria de exibir duas definições, a PODER e a LIDERANÇA.

PODER: Trata-se de conseguir resultados através de um poder herdado, conquistado onde seus subordinados executam o que é solicitado pela simples obrigação imposta.

LIDERANÇA: Trata-se da atividade onde direcionamos o trabalho de nossos subordinados e criamos as melhores condições para que eles possam exercer suas funções.

Existem gerentes de projetos que não exercem liderança, mas usam poder em suas equipes, ou seja, seus subordinados executam suas tarefas pelo simples fato de serem obrigados e não porque a fazer por prazer ou por consciência de que necessitam executá-las.

Mas, qual a diferença entre um GP que conquista sua equipe através do poder e o GP que conquista sua equipe através da liderança?

Simples: Quando conquistamos algo com PODER nosso subordinado irá realizar a atividade insatisfeito, e com todos outros sintomas psicológicos que se possa imaginar. Provavelmente o resultado de seu projeto não será tão bom quanto se esperava.

Quando conquistamos o trabalho de nossos subordinados através da liderança temos uma equipe que trabalha motivada e busca os melhores resultados.

Vejam abaixo os dois perfis de GPs

Gerente de projetos que se utiliza de PODER

- é arrogante
- prepotente
- não toma a frente
- não está preocupado com a equipe
- não é um bom ouvinte
- a equipe trabalha com ele por obrigação

Gerente de projetos que utiliza a LIDERANÇA como ferramenta

- é participativo
- trabalha para a equipe e pela equipe
- abre caminhos para facilitar o trabalho da equipe
- é um bom OUVINTE
- aceita opiniões e as avalia
- obtem os melhores resultados de suas equipes
- tem aprovação da equipe

Imagine o seguinte case:

Gerente que utiliza PODER como ferramenta
Seu recurso lhe procura e diz: "chefe, não vou conseguir realizar essa tarefa porque não conheço a fundo este módulo do ERP".
O chefe responde: "Não interessa! Se vire e se não me entregar a tarefa na data será demitido"

Gerente que utiliza LIDERANÇA como ferramenta
Seu recurso lhe procura e diz: "chefe, não vou conseguir realizar essa tarefa porque não conheço a fundo este módulo do ERP".O chefe responde: "Ok Fulando. Estarei verificando com os analistas mais experientes, qual deles pode lhe dar treinamento deste módulo uma semana antes da data da execução de sua tarefa, assim você estará apto a executá-la".

Preciso dizer qual deles irá colher o melhor resultado para seu projeto?

Liderar não é ser escravo ou submisso de sua equipe. Liderar não é entregar a eles o que desejam mas sim o que eles PRECISAM.

O poder pode ser usado? Pode e deve SOMENTE em situações extremas e mesmo assim, antes de usá-lo pense nas consequências.

Você tem sido um GP PODEROSO ou LIDER? Pense nisso.

Até a próxima!

Marcadores: , ,

Segunda-feira, 22 de Setembro de 2008

Gestão de aquisições: você conhece os tipos de contrato que podemos utilizar nas contratações em nossos projetos?













Normalmente nos deparamos com 3 tipos de contratos em projetos e eles são:

De custos reembolsáveis (CR) - Cost reimbursable
Tempo e material (T&M) - Time and material
Preço Fixo (PF) - Fixe Price (FP)

No Brasil, o contrato mais comum que encontramos na maioria das companhias é o PREÇO FIXO (PF) onde vendemos um pacote de X horas para realizar um projeto. Raramente encontraremos em nossa trajetória profissional algum cliente que contrate nosso serviço por um valor variável.

Veja logo abaixo um resumo do que vem a ser cada um destes 3 tipos de contratos.

Custos reembolsáveis (CR)
Neste tipo de contrato, os custos do fornecedor são reembolsados, acrescidos de um valor adicional. O comprador tem um grande risco neste tipo de contrato pois se desconhece os custos finais do contrato.

Na verdade o contrato de custos reembolsáveis é uma "categoria" de contratos e dentro dela temos os seguintes:

- Custo mais remuneração fixa (CMR) ou Custo mais percentual do custo (CMPC)
Neste tipo de contrato o comprador deve reembolsar todos os custos do fornecedor e ainda pagar uma remuneração em cima do custos. Parece contrato de português não é? Rs. Tanto é que o governo dos EUA proibiu a utilização deste tipo de contrato para aquisições federais.
Neste tipo de contrato o fornecedor não tem motivação para controlar seus gastos pois quanto mais gastar, mais receberá.

- Custo mais remuneração fixa (CMRF)
Neste caso o fornecedor é reembolsado na integridade do valor gasto e também recebe uma remuneração fixa.

- Custo mais remuneração de prêmio (CMRP)
Neste tipo de contrato o comprador paga todos os custos mais um bônus com base no desempenho, ou seja, quanto menos gastar, mais se recebe.

Tempo e material (T&M)
Este tipo de contrato geralmente é usado para valores reduzidos. O contrato baseia-se em um custo por hora ou por material e tem elementos de um contrato de preço fixo (no preço fixo por hora) e um contrato de custos reembolsáveis (nos custos de materiaise no fato de que o custo total é desconhecido).

Preço fixo (PF)
É o tipo de contrato mais comum do MUNDO. Neste tipo de contrato um preço fechado é acordado para o trabalho. É um contrato de grande risco ao fornecedor pois se existirem custos adicionais terão que ser assumidos por ele.

Marcadores: , , , , , , ,

Domingo, 21 de Setembro de 2008

A importância do levantamento de processos em projetos de implantação de sistemas de gestão integrada - ERP














Quando implantamos um sistema ERP em uma empresa é comum sugirem comentários dos usuários e até da alta diretoria referente ao sistema, dizendo que ele não atendeu as espectativas, que o sistema não cumpriu tudo aquilo que foi prometido pelo fornecedor no ato da venda.

Este assunto deve ser avaliado com cautela, pois alguns fatores importantes normalmente são desconsiderados quando se deseja implantar um ERP. Estarei escrevendo neste post sobre um dos fatores que é o mapeamento de processos.

Cada empresa possui seus processos que normalmente são "semelhantes" aos de outras empresas do mesmo segmento, mas com suas particularidades.

Um sistema ERP também é estruturado em processos que na maioria das vezes são genéricos e podem não atender em plenitude os atuais processos de negócio da empresa que irá recebê-lo.

A partir deste instante começam os problemas caso não exista um trabalho de mapeamento de processos antes da implantação do sistema.

Nem sempre os processos atuais da empresa que recebe o ERP são os mais adequados, apresentam falhas e geram problemas e custos. Na verdade, estes problemas já existiam, os processos já eram falhos mas com a chegada do ERP eles são expostos.

A implantação de um ERP sempre deve ser acompanhada de um trabalho de levantamento de processos. Esse trabalho deve ser dividido em duas fases:

Fase 1: AS-IS (Como é)
Uma equipe de processos deverá mapear todos os processos da empresa e documentá-los. O nível de detalhe varia de acordo com a necessidade.

Fase 2: TO-BE (Como será)
Processos mapeados e documetados, entramos na fase 2. Neste momento serão sugeridas melhorias nos processos. Essas melhorias são necessárias para que o sistema de gestão funcione em plenitude.

Basicamente é realizada a seguinte análise: Como são os processos e o que precisa ser melhorado para que o sistema funcione corretamente.

Em alguns casos podem existir processos que não poderão sofrer modificações. Nesta situação podesse estudar a possibilidade de customizar o sistema de gestão.

Executando o mapeamento e melhoria de processos antes da implantação do sistema, com certeza as metas de sucesso e o retorno esperado do investimento (ROI) serão alcançados.

Marcadores: , , , , , , ,

Quinta-feira, 18 de Setembro de 2008

Gerência de projetos em aplicações web é diferente

Achei o artigo abaixo de grande valor e por isso estou publicando aqui.

Todos os direitos reservados aos autores e ao WEBINSIDE.

O desenvolvimento de aplicações para a web é um capítulo à parte no que se refere ao processo de Gerenciamento do Projeto. Como aplicar as recomendações do PMBOK em aplicações para internet?

Por Eduardo F. A. Cardoso

Em co-autoria com Marcos Alberto Mochinski.

A disciplina de gerência de projetos tem sido aplicada em ambientes controlados como os da construção civil, da engenharia elétrica e até mesmo no desenvolvimento de software tradicional. Mas como aplicar Gerência de Projetos e as recomendações do PMBOK em desenvolvimento para web?

Ou seja, em projetos onde as principais características incluem um escopo do produto mal definido, o desenvolvimento de um produto novo, o envolvimento de pessoas com diferentes experiências e de diferentes áreas, a pressão constante sobre os prazos, a limitação de orçamento, o uso de novas tecnologias, a existência de riscos e a exigência de qualidade?

Ora, se em áreas de projetos mais controlados e com muito mais anos de estudo a gerência de projetos é aplicada, por que então não utilizá–la no desenvolvimento web de forma a obter melhores resultados? Seguindo essa linha de raciocínio, apresentamos a seguir algumas recomendações, considerações e dicas sobre cada uma das áreas do PMBOK quando aplicadas em desenvolvimento de aplicações para web.

Gerenciamento do escopo em projetos web

Aplicações web estão em constante evolução, o que dificulta a delimitação completa de escopo numa etapa anterior ao início da execução do projeto. Precisa–se, então, reconhecer que os projetos para internet são gerenciados como uma série de mini–versões que suportem os objetivos do negócio de maneira completa.

Esses objetivos representam uma visão ampla que se adapta às mudanças ocorridas no ambiente do negócio. Eles não podem ser reduzidos apenas a um rígido documento de requisitos. Dessa forma, o estabelecimento do escopo de projetos para ambiente web deve levar em conta a seguinte abordagem: estabelecer versões do projeto em fases, ter controle sobre restrições de tempo, definir metas atingíveis, definir prioridades e analisar riscos.

Em relação ao controle de alterações do escopo, o importante é formalizar o processo de mudança. Assim, é necessário estabelecer um comitê que avaliará a alteração que possa vir a afetar o escopo do projeto ou os requisitos do produto. É importante sempre se ter cuidado com a visão de que um site web é facilmente alterável.

Gerenciamento do tempo em projetos web

O ambiente web é um ambiente “imediato”, pois o tempo de disponibilização do produto no mercado (o chamado time–to–market) pode ser de algumas poucas horas e não é afetado por processos de manufatura. Assim, o cronograma deve ser um documento dinâmico, altamente flexível. Seu propósito é destacar as principais entregas do projeto e dependências entre as atividades.

Especialistas na área de desenvolvimento e design sabem como fazer seu trabalho e como organizar seu próprio tempo. Uma equipe de desenvolvimento web não pode ser comparada a robôs numa linha de montagem. Por isso, é importante que os membros da equipe do projeto tenham um planejamento, um cronograma, que os mostre o que é esperado deles e como eles são afetados pelo trabalho que os demais membros da equipe estão realizando.

Gerenciamento de custos em projetos web

Mesmo que possa ser trabalhosa, recomenda–se o uso da técnica EVM (Earned Value Management, ou Análise do Valor Agregado) para controle de custos. A EVM proporciona um controle explícito dos custos e monitoramento do trabalho produzido, evitando que se recorram a fatores típicos dos projetos web como horas–extras, convocação não planejada de novos profissionais (recursos) para a equipe e muito retrabalho não previsto.

Gerenciamento da qualidade em projetos web

Qualquer profissional de TI sabe da importância e do desafio envolvido no desenvolvimento de um software de qualidade. Em aplicações para web o desafio é ainda maior, em função de novos padrões de qualidade que surgiram para esse tipo de projeto. Os principais a serem observados são usabilidade e navegação, compatibilidade com navegadores e sistemas, funcionalidade, performance e carga, conteúdo, e segurança.

SHELFORD (2003) recomenda que se faça o “lançamento suave” da aplicação para o ambiente de produção. Isto é, faz–se o deploy de todos os elementos aprovados no ambiente de teste, mas mantém–se o acesso restrito, via login especial ou via URL desconhecida do público, até que sejam feitos alguns retestes no ambiente de desenvolvimento. Ou seja, até que o aplicativo ou site esteja estável. É durante essa etapa de testes que se faz a aceitação formal do projeto, ou processo de encerramento do projeto.

Gerenciamento de recursos humanos em projetos web

Projetos web são projetos multidisciplinares onde há, necessariamente, o envolvimento de pessoas de várias áreas como desenhistas, programadores, analistas de sistemas, jornalistas, revisores ortográficos e qualquer outro profissional que conheça o negócio que o projeto deva atender.

De um modo geral, projetos web terão em suas equipes de desenvolvimento as seguintes funções: produtor, designer, programador de interface, programador cliente/servidor, revisor ortográfico, testador, analista de sistemas, analista de banco de dados, analista de infra–estrutura, iconografista e gerente de projeto. Com todo esse pessoal e com todas as diferenças de tarefas, objetivos, cultura e formação entre os membros da equipe, evidentemente os projetos web terão alto grau de conflito. A gerência de conflitos é, então, o grande desafio do processo de gerenciamento de recursos humanos em projetos web.

Gerenciamento das comunicações em projetos web

Devido à multidisciplinaridade, a comunicação nesse tipo de projeto é vital para o sucesso final do empreendimento. Cabe ao gerente de projetos aplicar as melhores práticas de comunicação oral, escrita e não verbal. Ele precisa conhecer o processo de comunicação, ter ciência das barreiras culturais, buscar e dar feedback quando necessário.

Usar linguagem simples, usar redundância quando a situação pedir, saber ouvir e não só falar. Boa dosagem entre os tipos de comunicação deve ser aplicada, pois a tendência é dar preferência à comunicação via correio eletrônico ou mensagens instantâneas, mesmo quando o colega de trabalho está sentado na mesa à frente.

Em projetos web, o produtor é a pessoa responsável por determinar o encerramento do projeto, cabendo ao gerente de projetos facilitar e dar andamento ao processo. Mesmo em projetos com clientes externos responsáveis pelo aceite, cabe ao produtor dar o aceite interno, ou seja, formalmente ele assume que o projeto está apto para ser submetido à avaliação externa ou entrar em produção nas instalações do cliente.

Gerenciamento de riscos em projetos web

Em projetos web, o gerente de projetos não pode se contentar com um gerenciamento de riscos que seja apenas intuitivo.

Devido ao limitado tempo de desenvolvimento, é comum que projetos web utilizem um processo muito simples de gerenciamento de risco em que a equipe identifica e monitora, por exemplo, os 10 principais (top ten) riscos do projeto. Uma lista de riscos como essa pode ser impressa numa única folha e o status dos riscos pode ser rapidamente revisado semanalmente.

De um modo geral, há duas razões que explicam porque sistemas para web estão mais sujeitos a riscos do que os sistemas tradicionais. A primeira razão é óbvia: por sua natureza, uma aplicação para a internet está mais exposta a toda a população do mundo (hackers de todas as partes tentando sobrecarregar a aplicação ou retirá–la do ar, ou tentando roubar informações ou dinheiro, ou incluir imagens impróprias nos sites das empresas, etc). A outra razão é que, mesmo sem enfrentar esses comportamentos destrutivos, os sistemas web devem estar preparados para suportar o acesso concorrente de milhares (ou milhões) de usuários sem que isso gere a indisponibilidade do sistema.

Gerenciamento de aquisições em projetos web

De um modo geral, pode–se dizer que projetos web não possuem particularidades especiais em relação ao gerenciamento de aquisições estabelecido pelo PMBOK.

Gerenciamento de integração em projetos web

Para o bom desenvolvimento de um plano de gerenciamento de projeto web é necessário um bom nivelamento de habilidades e conhecimentos de todos os envolvidos. Para o time de projetos é fundamental que cada um conheça bem a sua função e a função dos demais companheiros. Além disso, espera–se que os envolvidos em um projeto web conheçam TI e, fundamentalmente, internet.

Todos os envolvidos devem estar bem familiarizados com os recursos e com o estado–da–arte da internet, pois só assim proporcionarão uma boa integração do projeto. Portanto, recursos multimídia, ferramentas como blog, comunicadores de mensagens instantâneas, salas de bate–papo, sites e serviços mais conhecidos devem ser de amplo domínio da equipe, pois não se pode projetar sistemas para web sem se conhecer a própria web.

Como conclusão, pode–se afirmar que a multidisciplinaridade das equipes de trabalho, a crescente evolução tecnológica do setor, o processo iterativo de desenvolvimento, a constante corrida contra o tempo e a capacidade de alcance global que aplicações web têm, certamente são algumas das características que justificam a necessidade de se dar atenção especial aos aspectos relativos aos processos de gerenciamento do projeto.

Sob a perspectiva de negócio e de estratégia de desenvolvimento, o que deve ser ressaltado é que a prática de Gerenciamento de Projetos é fator determinante para o sucesso de um projeto. [Webinsider]

………………………………………………..

Referências:

_________. A Guide to the Project Management Body Of Knowledge: PMBOK guide – Third Edition ed. Four Campus Boulevard, Newtown Square, Pensilvânia, EUA: Project Management Institute, Inc, 2004. ISBN 193069945X.

SHELFORD, Thomas J.; REMILLARD, Gregory A. Real Web Project Management: Case Studies and Best Practices from the Internet. Boston, MA: Addison Wesley, 2003. ISBN 0321112555.

Nota: Project Management Body of Knowledge (PMBOK) é um documento desenvolvido pelo Project Management Institute (PMI) que agrega o conjunto de conhecimentos em gerenciamento de projetos e inclui práticas tradicionais comprovadas amplamente aplicadas e práticas inovadoras que estão surgindo na profissão.

Autores:
Eduardo Ferreira de Abreu Cardoso Junior, PMP (Project Management Professional), engenheiro eletrônico, gerente de desenvolvimento Internet na Positivo Informática.

Marcos Alberto Mochinski, PMP (Project Management Professional), analista de sistemas, gerente de desenvolvimento Internet na Positivo Informática.

.

Sobre o autor

Eduardo Ferreira de Abreu Cardoso Junior (eduardo.cardoso@educacional.com.br), é PMP (Project Management Professional), engenheiro eletrônico e gerente de desenvolvimento Internet na Positivo Informática.

PM FASTRACK em Português

É isso ai pessoal. O RMC liberou para download a versão em português do consagrado simulado para o exame PMP. Trata-se de uma versão demo com acesso somente a 24 questões no PMP, 3 no SUPER PMP.

O programa é completo, porém para habilitar as demais questões é preciso pagar a SALGADA Licença de uso.

Link para download:
http://www.rmcproject.com/free/ftdemo/pm_fastrack-pmp_5.2.1-pt.zip

Veja abaixo alguns exemplos de tela do FASTRACK em português BR:

































Marcadores: , , ,

Domingo, 24 de Agosto de 2008

O gráfico de CURVA S

Uma importante ferramenta na mão do gerente de projetos sem dúvida alguma é o gráfico de curva S. Ele basicamente serve para representar graficamente custos acumulados, horas de mão-de-obra, percentual de trabalho ou quantidades, indicando sua evolução no tempo.

Para gerar um gráfico de curva S, você precisará ter o custo previsto (planejado) e irá comparar com o real. A informação que o gráfico lhe exibir serve para auxiliar o gerente de projetos a tomar decisões, por exemplo, o custo de execução das atividades da semana 3 estavam estimados em em 150, o real foi 170. O custo aumentou. Com base nessa informação de desvio o GP pode tomar medidas para fazer o custo final permanecer dentro do orçamento como "eliminar" atividades que não sejam fundamentais nas próximas semanas,.

Veja abaixo um exemplo de gráfico de curva S:













Este gráfico nos mostra que, em grande parte do projeto saimos do custo estimado (linha vermelha), ou seja, esse projeto teve problemas com orçamento.

Marcadores:

Quinta-feira, 14 de Agosto de 2008

Diagramas de rede ... porque um pouquinho de PMBOK vai bem :)

Sei que no dia-a-dia realizamos a definição e sequenciamento das atividades diretamente no software que utilizamos para gerar nossos cronogramas, sem fazer um diagrama de rede formal (digamos assim), mas é interessante saber como funciona o sequenciamento de atividades através dos diagramas de rede. Essa teoria é importante principalmente para quem vai prestar prova para PMP ou CAPM.

Segue abaixo trechos do PMBOK sobre o assunto:

Seqüenciamento de atividades
O seqüenciamento de atividades envolve a identificação e documentação dos
relacionamentos lógicos entre as atividades do cronograma. As atividades do
cronograma podem ser seqüenciadas logicamente usando as relações de precedência
adequadas, além de antecipações e atrasos, para dar suporte ao desenvolvimento
posterior de um cronograma do projeto realista e alcançável. O seqüenciamento pode
ser realizado usando um software de gerenciamento de projetos ou técnicas manuais.
As técnicas manuais e automatizadas também podem ser usadas em conjunto.

Técnicas para gerar o sequenciamento:


.1 Método do diagrama de precedência (MDP)

Precedence Diagramming Method (PDM)
O MDP é um método de construção de um diagrama de rede do cronograma do
projeto que usa caixas ou retângulos, chamados de nós, para representar atividades e
os conecta por setas que mostram as dependências. A Figura 6-5 mostra um diagrama
de rede do cronograma do projeto simples desenhado usando o MDP. Esta técnica
também é chamada de atividade no nó (ANN) e é o método usado pela maioria dos
pacotes de software de gerenciamento de projetos.

O MDP inclui quatro tipos de dependências ou de relações de precedência:

- Término para início. A iniciação da atividade sucessora depende do término da
- Término para término. O término da atividade sucessora depende do término
da atividade predecessora.
- Início para início. A iniciação da atividade sucessora depende da iniciação da
atividade predecessora.
- Início para término. O término da atividade sucessora depende da iniciação da
atividade predecessora.

No MDP, término para início é o tipo mais comumente usado de relação de
precedência. As relações do tipo início para término são raramente usadas.












.2 Método do diagrama de setas (MDS)
Arrow Diagramming Method (ADM)
O MDS é um método de construção de um diagrama de rede do cronograma do
projeto que usa setas para representar atividades e as conecta nos nós para mostrar
suas dependências. A Figura 6-6 mostra um diagrama de lógica de rede simples
desenhado usando MDS. Esta técnica é também chamada de atividade na seta (ANS)
e, embora menos adotada do que o MDP, ainda é usada no ensino da teoria de rede do
cronograma e em algumas áreas de aplicação.

O MDS usa somente dependências do tipo término para início e pode exigir o
uso de relacionamentos “fantasmas” chamados de atividades fantasmas, que são
mostradas como linhas pontilhadas, para definir corretamente todos os
relacionamentos lógicos. Como as atividades fantasmas não são atividades reais do
cronograma (não possuem conteúdo de trabalho), é atribuída a elas uma duração nula
para fins de análise de rede do cronograma. Por exemplo, na Figura 6-6, a atividade
do cronograma “F” depende do término das atividades do cronograma “A” e “K,” e
também do término da atividade do cronograma “H.”

O gerente de projetos precisa ter conhecimento na área do projeto que vai gerenciar?















A um tempo atrás estava em uma roda de amigos onde falaram que o GP não precisa ter conhecimento específico da área a qual vai gerenciar um projeto. Digamos que 30% da turma concordou, 20% ficou em cima do muro e os outros 50% discordaram e eu estava nesse grupo.

Entendo que, obviamente são meus recursos operacionais que precisam ter domínio técnico do que será executado e que não preciso ser um especialista no assunto, porém, como vou gerenciar um projeto sem ter a mínima noção?

É, falaram que eu posso contar com opinião e auxílio dos especialistas. Opa eu concordo com isso, mas se eu for "terceirizar" cérebro para tudo o que vou fazer afinal? Como vou ser responsável por algo que não conheço, que dependo 100% de alguém para me dizer o que é certo ou erro e que não tenho base para discernir o que é certo e o que é errado sozinho?

Vamos a um exemplo. Trabalho com ERP e também com mídias on-line. São os dois segmentos que possuo conhecimento portanto estou apto a gerenciar projetos dessas áreas.

Se me "jogarem" um projeto de infraestrutura de TI na mão, como fica? Cá entre nós não acho que daria muito certo.

Vamos mais longe. E se colocarem na sua mão um projeto de construção de uma unidade de distribuição.

Não sei não ... essa idéia do GP 100% passivo à opinião dos recursos sem ter capacidade para analisar se a informação que estão lhe passando realmente faz sentido, se é a melhor não me convenceu.

Segunda-feira, 11 de Agosto de 2008

Modelo de maturidade OPM3










Estava navegando a pouco e encontrei um artigo que fala sobre o modelo de maturidade OPM3. Uma visão básica e introdutória e que vale apena ser compartilhado. Leia abaixo na integra.
Obs: todos os créditos são do autor do artigo.

Maturidade Organizacional e o Modelo de Avaliação PMI-OPM3
Autor: Alonso Mazini Soler
amsol@j2da.com.br
Introdução
Ultimamente, alguns grandes ‘gurus ’ da
Administração t êm apregoado a importância
do gerenciamento ef etivo de projetos como
estrat égia de sucesso das organizações.
Como exemplo, Tom Peters em ‘Liberation
Management ’ diz que "nós agora vivemos em
um mundo de projet os (...) e para administrá-lo
será necessário um mundo de novos
conhecimentos e habilidades”. Desde então,
empresários e executivos dos mais diferent es
tipos de organizações têm despertado para as
vantagens de investir no desenvolv imento de
um context o organizacional propício e
f acilitador para que os seus projetos possam
resultar em retornos previsíveis,
potencializando a gestão estratégica da
organização. Nesse sentido, uma miríade de
conceitos, produt os e serv iços novos tem
dominado e seduzido gest ores que se vêem
às voltas com a problemática de discernir e
separar aquilo que realmente é útil daquilo que
talvez não o seja, durante o processo de
criação de um ambiente f avorável à execução
adequada de projet os e inic iativas
organizacionais.

Nesse contexto, no início de 2004, o PMI -
Project Management Institute - lançou o seu
Modelo OPM3, acrônimo de Project
Management Maturity Model, desenvolv ido a
partir da pesquisa com outros tantos modelos
pré-ex istent es de avaliação de Maturidade
Organizacional e do apoio anônimo de
aproximadamente 800 voluntários de mais de
35 países, inclusive do Brasil.

O Modelo OPM3 v isa of erecer uma estrutura
f ormal capaz de traduzir estratégias em
resultados de sucesso, consist entes e
previsíveis. Uma estrutura de melhoria
contínua do ambient e de gestão de projetos
das organizações construída através da
recomendação de ‘Boas Práticas’, geralment e
aceitas e previament e experimentadas por
seus assoc iados. Desse modo, em princípio, o
Modelo OPM3 retrata uma trilha segura e
ref erenciada, capaz de orient ar os gestores
organizac ionais nos seus investimentos em
iniciativas de aprimoramento da operação de
gestão de projet os. Conhecer e aplicar o
Modelo PMI-OPM3 é hoje, portanto, um modo
relativamente ef icaz de propor mudanças
organizac ionais, de modo situacional,
destinadas à melhoria da gestão de projet os.

O Modelo PMI-OPM3 de Maturidade em
Ger enciamento de Projetos
Um Modelo de Maturidade Organizacional é
uma estrutura conceitual, composta por
processos bem est abelecidos, através da qual
uma organização desenvolve-se de modo
sistêmico a f im de atingir um estado f uturo
desejado. A cada degrau alcançado nessa
jornada, o modelo reconhece e sinaliza o
amadurec imento progressivo da organização.
Organizações mais maduras deveriam,
teoricament e, proporc ionar result ados
melhores e de modo mais ef iciente.

No caso do Gerenciament o de Projetos, um
Modelo de Maturidade é aquele que aponta as
trilhas já demarcadas pelas quais as
organizações deveriam passar e os marcos
que deveriam atingir sequencialmente, a pont o
de perseguir o objetivo de resultados mais
ef etivos e prev isíveis na gestão de seus
projet os.

Porém, quais deveriam ser hoje as prioridades
da sua organização a f im de aprimorar a
gestão dos seus projetos? Investir em
treinamento dos gestores e na sua
certif icação? Na compra e disponibilização de
novas f erramentas e sistemas com maior
volume de f uncionalidades? Na otimização e
padronização de processos e documentos sob
a forma de metodologia? Por onde começar?
Eis a questão a ser respondida pelo Modelo
de Maturidade OPM3!

O Modelo OPM3 é uma estrutura que
proporciona benéficos v isíveis às
organizações que o adotam: (a) Permit e
habilit ar a organização a promover os projet os
certos, da maneira certa, alinhados
estrat egicament e em uma economia dinâmica
e global, (b) Permit e a flexibilidade de ser
aplicado à diversos tipos de organizações,
através de dif erentes áreas de atuação, ramos
de negócios, tamanhos, localizações
geográf icas, etc., (c ) Permite promover a
conscientização e esclarecer a questão da
maturidade organizacional por toda a alt a
direção e (d) Permite associar diret amente o
sucesso da organização à gestão ef icaz e
ef iciente de projet os.

A aplicação do Modelo OPM3 está baseada
em três elementos chave, inter-relacionados
de modo seqüencial:

1) O CONHECIMENTO dos componentes do
modelo de maturidade;
2) O questionário de AUTO-AVALIAÇÃO do
estágio de maturidade da organização e,
3) O PROCESSO DE MELHORIA capaz de
orient ar gestores a deslocar a organização de
um estágio atual para um estágio f uturo
desejado de mat uridade.

Vejamos alguns desses element os.
Fase 1: Os Componentes do Modelo OPM3
O primeiro passo para a aplicação do Modelo
OPM3 sugere o conheciment o dos elementos
que o compõem.

O elemento f undamental do Modelo OPM3 é o
conjunt o de conhecimentos agregados e
interligados, elaborados através do trabalho
voluntário de especialistas no mundo inteiro e
recomendados de modo específ ico e
situacional às dif erentes organizações. Esse
conjunt o de conheciment os está represent ado
no Modelo OPM3 sob a f orma de diretórios de
Inf ormação e é composto pelos seguint es
elementos básicos:

a) Boas Práticas geralmente aceitas e
experimentadas, representando a habilidade
de se conduzir projetos de modo mais
consist ent e e prev isível;
b) Capacidades ou pré-requisitos assoc iados a
cada uma das Boas Práticas;
c) Result ados que comprovam a ex istênc ia de
uma ou mais Capacidades;
d) Indicadores Chave de Desempenho (KPIs),
que possibilitam medir os result ados atingidos;
e) Caminhos e ligações lógicas que agregam

Capacidades às Boas Práticas.
As Boas Práticas e Capacidades, por sua vez,
estão relacionadas a dois dif erentes fatores
chaves dentro do modelo OPM3:

a) Domínios de abrangência, sobre os quais
se desenvolvem as indicações e
recomendações de amadureciment o
organizac ional. Os domínios mencionados no
Modelo OPM3 ref erem-se a Projetos,
Programas e Portf ólio;
b) Est ágios de amadurecimento dos processos
organizac ionais, associados às f ases do
modelo de melhoria contínua de processos tal
como desc ritos por E. Deming e W. Shewhart
no início do século passado. Os est ágios de
amadurec imento são descrit os no Modelo
OPM3 como: Estágio de Padronização, de
Mensuração, de controle e de Melhoria
Contínua.
A Figura 1 abaixo ilustra esses componentes e
a sua complexidade. I ndicando que a
perseguição da maturidade organizacional
pode ser v ista como uma jornada contínua de
aprimoramento de processos.
Em suma, Maturidade Organizac ional pode
ser definida como o grau em que a
organização aplica as Boas Práticas de
gerenciamento de projetos, em cada um dos
domí nios est abelecidos: Projet os, Programas
e Portfólio.

Figura 1: Dimensões da Maturidade
Organizacional através do Modelo OPM3

Fase 2: A Auto Avaliação
O passo seguint e da aplicação do modelo f az
alusão a um instrumento de auto-avaliação,
constituí do por um questionário de escolhas
dicot ômicas (sim ou não), através do qual o
usuário analisa e responde sobre a presença
ou não de processos f ormais associados ao
ciclo de v ida do gerenciamento de projetos, t al
como ref erenciado pelo Guia Project
Management Body of Knowledge do próprio
PMI.

O result ado da aplicação do questionário é
tratado como entrada do Modelo OMP3 que,
de acordo com as respostas proporcionadas,
define uma list a de Boas Práticas que,
provavelment e, já estão present es no modelo
de gest ão da organização, e uma segunda
lista de Boas Práticas que seriam
recomendadas à organização.

Fase 3: O Processo de Melhoria
Por f im, o Modelo OPM3 est abelece que,
diante da lista de Boas Práticas
recomendadas, a organização f aça uma
análise de v iabilidade e priorização e
estabeleça um plano compost o pela melhor
seqüência de ações de melhoria, apropriadas
às suas condições situacionais, v isando
alcançar maior maturidade.

O ciclo de melhoria contínua consolida-se pela
execução desse plano de ação e pelo
recomeço periódico da seqüência propost a
desde a f ase de auto-avaliação
organizac ional.

A aplicação do Modelo OPM3 trata-se,
port ant o, de uma jornada de aprimorament o
que se sobrepõem aos objetivos imediat os e
tangíveis em razão do aprimoramento real dos
processos organizacionais e da conquista de
resultados mais adequados e prev isíveis dos
projet os da organização.

Discussão sobr e a Aplicação do Modelo
OPM3
Por algumas vezes, est e autor esteve às
voltas com a aplicação do modelo OPM3, na
f unção de Consult or Externo às organizações
avaliadas, e registrou algumas percepções
hav idas de prof issionais avaliados.

a) O f ato de não haver ainda tradução do
Modelo OPM3 para a língua port uguesa,
dif icultou bastante o entendimento dos
partic ipant es e a aplicação do Modelo;
b) O f ato de não haver ainda uma ref erência
de processos para os domí nios de Programa e
Portf ólio, tal qual exist e para o domínio de
Projet os (na f orma do Guia PMI-PMBoK),
tornou a interpretação das Boas Práticas para
esses domínios repetitiva e desprov ida de
sentido aplicado;
c) O questionário de auto-avaliação foi
considerado repetitivo e burocrático;
d) A ausência de um grau mensurável
associado à avaliação da mat uridade, tal como
estabelecem outros modelos de avaliação de
maturidade organizac ional - que costumam
medir mat uridade através de uma escala de 1
a 5 - dificulta o ent endimento, a comunicação
interna e o estabelecimento de metas
mensuráveis e compromissos para o
aprimoramento da maturidade organizacional
através do modelo OPM3.

Caso deseje ver em PDF com as ilustrações, acesse:
http://www.cin.ufpe.br/~fabio/MaterialparaPesquisa/PGP%20-%20Organizacoes/AR%20-%20Maturidade%20Organizacional%20e%20OPM3.pdf

Marcadores: , ,

Domingo, 10 de Agosto de 2008

Como medir se um projeto está de acordo com o planejado?














Ainda encontramos muitas organizações onde a medição de desempenho/ custo em um projeto não é algo praticado. Na realidade, isso não é algo para se espantar se partirmos do ponto de que, para muitas empresas, quando falamos em projetos estamos limitados a "cronograma".

Saber se o projeto está dentro do orçamento, se está dentro do prazo, se o retorno é o esperado é algo muito importante, tendo em vista um total controle do que está acontecendo e com essas informações, poder corrigir desvios e solicitar mudanças.

Veja abaixo algumas técnicas para medição em um projeto:

1- Indicadores de progresso Orçamento no término (ONT): trata-se do valor que você tem planejado para gastar com seu projeto. Depois que você adicionar todos os custos para executar suas atividades, todos os custos com seus recursos, terá um número final. Esse número é o seu ONT.

% Real completo: é o percentual que seu projeto já concluiu com base no total.
Exemplo: imagine que deveriam ter sido trabalhadas 300hs de um total de 1000 ou seja, 30%. Porém digamos que foi constado que na verdade sua equipe concluiu 35%. Esses 35% é o seu percentual real completo.

Valor planejado (VP): é o valor que você planejou gastar com seu projeto até agora.
Fórmula: ONT x % planejado
Exemplo: você tem um ONT de R$200.000,00 e o cronograma diz que seu percentual planejado é de 30%, então o valor planejado é de R$60.000,00 (200.000 x 30%).

Custo real (CR): é o que realmente foi gasto (trabalhado) em $ até o atual momento.

Valor agregado (VA): é o valor que o projeto já retornou. Cada hora que cada membro da equipe trabalha acrescenta valor ao projeto. Você pode calcular isso pegando o percentual de horas que a equipe realmente trabalhou multiplicando isto pelo ONT. Se você teve um percentual completo de 35% e o ONT é R$200.000,00 então seu VA é de R$70.000,00
Fórmula: ONT x percentual de trabalho realizado.

2- Indicadores de Variação de custos (VC): informa a diferença entre o que você planejou gastar e o que realmente gastou.
Fórmula: VC=VA-CR

Variação de prazos (VDP): O funcionamento da variação é simples. Quanto maior a diferença entre o que você planejou e o que realmente recebeu, maior a variação, então, para saber o quão adiantado ou atrasado você está no cronograma, apenas subtraia o VP do VA.
Fórmula: VDP= VA-VP
Se a variação for positiva, seu projeto vai bem. Se for negativa, seu projeto está com problemas.

3- Indicadores de desempenho
Índice de desempenho de custos (IDC): serve para você saber se está acima ou abaixo do orçamento.
Fórmula: IDC= VA/CR

Índice de desempenho de prazos (IDP): serve para saber se você está adiantado ou atrasado no cronograma. Quando você está adiantado no cronograma, significa que ganhou mais do que planejou, então o VA (valor agregado) será maior que o VP (valor planejado).
Fórmula: IDP= VA/VP
Se o IDP foir maior que 1, significa que você está adiantado no cronograma. Se o IDP for menor que um, significa que você está atrasado.

IMPORTANTE: Você está no orçamento quando: seu IDC é maior que 1 e seu VC é positivo.
Quando esta situação ocorre, seus custos reais são menores do que o valor agregado, o que significa que o projeto está desenvolvendo mais do que custa.

Você está fora do orçamento quando: seu IDC é menor que 1 e seu VC é negativo.
Quando esta situação ocorre, seus custos reais foram maiores do que o valor agregado, isto significa que seu financiador não está recebendo o dinheiro dele de volta do projeto.

Marcadores: , , , , ,

Sexta-feira, 8 de Agosto de 2008

Quais são as responsabilidades do gerente de projetos durante os processos de execução?











Existem alguns profissionais que acreditam que o trabalho do gerente de projetos é nulo na fase de execução, onde está é pertinente somente aos recursos técnicos.

Essa situação não é verdadeira. Apesar do grande esforço do GP realmente ocorrer durante os processos de planejamento, ele tem um importante papel durante a execução do projeto.

Nesse momento o GP "serve" a equipe. Os auxilia "politicamente" na execução das tarefas. Ele serve como integrador das tarefas que estão sendo executadas, as acompanhando para que não percam o sincronismo. Acompanha a execução para que elas não saiam do eixo.

E mudanças aprovadas e ações preventivas? Sim, ele também é responsável por acompanhar a execução das mudanças aprovadas pelo comitê e ações preventivas para garantir que serão implementadas corretamente.

O GP também deve garantir que tudo que está sendo executado, está sendo feito de acordo com a metodologia e o baseline. Se na metodologia diz que a cada tarefa concluída o recurso técnico tem que enviar um e-mail para o diretor, o GP tem que garantir que esse e-mail está sendo enviado.

Parou por ai? Não. Nesta fase o GP também trabalha na contratação de recursos humanos e recursos técnicos.

Ahhh já ia me esquecendo. Antes de tudo isso ocorre o KICK-OFF que trata-se da reunião onde ocorre o START do projeto (execução). O Kick-off pode ocorrer várias vezes e não somente uma. Como assim? É, se seu projeto, por exemplo é composto por fases, a cada faze pode ocorrer um kick-off. No Kick-off apresentam-se os objetivos do projeto, as principais premissas,as exclusões (o que não será contemplado), a WBS destacando "quem reponde por o que", plano de comunicaçã