Link: http://certificacaopmp.wordpress.com/
Autor: Fernando Santos Dantas
O blog trata de diversas questões sobre o exame de certificação PMP, como preparar-se, simulados, orientações de estudo etc.
sábado, 23 de outubro de 2010
Os 7 passos do gerenciamento de projetos
Publicado em: http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/GerencProjetos.mspx
Autor: Fernando C. Barbi
O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações a medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.
Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.
Muitas empresas estão adotando a estrutura de projetos no seu dia-a-dia. Desde a concepção de um novo software até a implantação dos procedimentos de atendimento a clientes, desde a construção de uma ponte até a revisão dos processos de venda com vistas a aumentar a taxa de fechamento de negócios, muitos empreendimentos no seio das organizações se enquadram na classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de projetos está ganhando terreno por permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organização. Sabendo da importância de se gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas habilidades de gerenciamento de projeto.
Tudo começa com a contratação de uma empresa para tocar o projeto ou a definição dos colaboradores internos que integrarão a equipe de projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser formalizado com um documento que se chama de “termo de início do projeto”. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o projeto e todos estão envolvidos com a sua execução.
A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.
Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.
A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.
Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.
Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.
Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:
Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.
Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.
Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.
Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.
O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.
A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.
O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.
Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.
É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.
No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto", um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.
Veja estas atividades que representam as linhas gerais de um projeto de sistema:
Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.
O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.
Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc...
Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.
É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.
A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.
Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:
Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.
O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.
Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.
Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.
O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro".
(*) Fernando C. Barbi (mailto:%20fernando@hexxa.com.br)
Fernando é Gerente de Projetos especializado em TI com 18 anos de experiência na área e colaborador da ADVANCE Marketing – empresa de treinamento consultoria em gestão, marketing e vendas (http://www.advancemarketing.com.br/)
Autor: Fernando C. Barbi
O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações a medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.
Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.
Muitas empresas estão adotando a estrutura de projetos no seu dia-a-dia. Desde a concepção de um novo software até a implantação dos procedimentos de atendimento a clientes, desde a construção de uma ponte até a revisão dos processos de venda com vistas a aumentar a taxa de fechamento de negócios, muitos empreendimentos no seio das organizações se enquadram na classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de projetos está ganhando terreno por permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organização. Sabendo da importância de se gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas habilidades de gerenciamento de projeto.
Tudo começa com a contratação de uma empresa para tocar o projeto ou a definição dos colaboradores internos que integrarão a equipe de projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser formalizado com um documento que se chama de “termo de início do projeto”. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o projeto e todos estão envolvidos com a sua execução.
1. Escolha e adote uma metodologia
Uma metodologia é um processo a seguir que dá maior controle sobre os recursos que serão utilizados no projeto. Controlando melhor o processo a equipe será mais eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia é importante porque permite evitar práticas que levam ao insucesso e com isso reproduzir o sucesso.A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.
Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.
2. Comunique-se: não é só o peixe que morre pela boca!
Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse tipo de prática, conhecida por "rádio-peão", dando informações claras e confiáveis sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.
3. Defina o escopo do projeto e detalhe as atividades
O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.
Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.
Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:
| Profissional | Tarefa 1 | Tarefa 2 | Tarefa 3 | T.Total (h) | Custo/h | Custo |
Gerente de projeto | 20 | 0 | 3 | 23 | 150,00 | 3.450,00 |
Líder de projeto | 10 | 3 | 2 | 15 | 80,00 | 1.200,00 |
Analista Sênior | 20 | 0 | 0 | 20 | 50,00 | 1.000,00 |
Programador | 0 | 40 | 20 | 60 | 30,00 | 1.800,00 |
Testador/Documentador | 0 | 20 | 30 | 50 | 15,00 | 750,00 |
Total | - | - | - | 168 | - | 8.200,00 |
Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.
Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.
Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.
Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.
O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.
A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.
O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.
Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.
4. Conheça os envolvidos e monte seu time
Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.
No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto", um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.
5. Desenvolva o cronograma junto com quem põe a mão na massa
Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por tabela um orçamento da sua parte.Veja estas atividades que representam as linhas gerais de um projeto de sistema:
Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.
O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.
Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc...
Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.
É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.
6. Monitore os riscos e seja pró-ativo
Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas diferentes: a monitoração do risco e controle do risco.A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.
Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:
Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.
O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.
7. Formalize o início e o encerramento do projeto
O início do projeto é um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto começou, o gerente pode não conseguir apoio algum. Além disso, este documento funciona como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o projeto começou e todos os “arrolados” devem participar.Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.
Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.
Conclusão
Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com "um olho no peixe e outro gato". O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro".
(*) Fernando C. Barbi (mailto:%20fernando@hexxa.com.br)
Fernando é Gerente de Projetos especializado em TI com 18 anos de experiência na área e colaborador da ADVANCE Marketing – empresa de treinamento consultoria em gestão, marketing e vendas (http://www.advancemarketing.com.br/)
quinta-feira, 21 de outubro de 2010
Princípios Chave para o Sucesso em Gestão de Projetos
Os gerentes de projeto devem enfocar nas três dimensões do sucesso do projeto. Posto em termos simples, o sucesso de um projeto significa alcançar todos os resultados do projeto dentro do prazo prazo, dentro de orçamento, e com um nível de qualidade aceitável aos patrocinadores. O gerente de projeto deve manter o foco da atenção da equipe em alcançar essas metas.
Planejamento é tudo - e é contínuo. Em um coisa todos os textos e autoridades de Gerenciamento de Projetos concordam: A atividade única mais importante que gerentes de projeto tomam parte é o planejamento - planos detalhados, sistemáticos e envolvendo a equipe são o alicerce para o sucesso do projeto. E quando os eventos do mundo real conspiram contra seu plano, o gerente de projeto deve fazer um novo plano refletindo essas mudanças. Então planejamento e replanejamento devem ser o estilo de vida para gerentes de projeto.
Os gerentes de projeto devem sentir e transmitir para a equipe um senso de urgência. Porque projetos são empenhos finitos com tempo, orçamento, e outros recursos limitados, eles devem avançar continuamente rumo à conclusão. Já que a maioria de membros de equipe tem outras prioridades, cabe ao gerente de projeto manter sua atenção nas metas e prazos finais do projeto. Reuniões periódicas de acompanhamento e alertas são essenciais para corrigir os desvios tão logo seja identificados.
Os projetos bem sucedidos usam um método de trabalho estabelecido. Nós sabemos o que funciona. Os modelos como o ISD e outros descrito neste texto podem ajudar a assegurar que os padrões profissionais e as melhores práticas sejam aplicadas em nossos planos de projeto. Esses modelos não servem somente para garantir a qualidade do projeto, eles ajudam a minimizar retrabalho e consequentemente otimizar o tempo do gerente de projetos. Então quando pressões de tempo ou orçamento parecem encorajar pequenos cortes, cabe ao gerente de projeto identificar e defender o melhor ciclo da vida de projeto para o trabalho.
Todos os resultados e todas as atividades do projeto devem ser visualizados e comunicados com detalhes vívidos. Em resumo, o gerente de projeto e a equipe de projeto devem se apressar em criar um retrato mental das metas, objetivos e resultados do projeto de forma que todo esforço é focado na mesma direção. Evite descrições vagas a todo custo: defina, explique, exemplifique, prototipe, ponha em termos claros e certifique-se de que todo mundo concorda com isso.
Deliverables devem evoluir gradualmente, em refinamentos sucessivas. Pode ser simplesmente caro demais e arriscado demais ter que refazer um deliverable do projeto por erro ou omissão. Construa um pouco de cada vez, obtenha revisões e aprovações com ampliação, e mantenha uma evolução controlada.
Os projetos exigem aprovações e critérios de conclusão claramente definidos pelos patrocinadores. Ao final de uma etapa do projeto o Gerente deve ter uma reunião formal para entregar os deliverables de acordo com os critérios de conclusão de fase. É fundamental que os patrocinadores do projeto participem dessa reunião em que são apresentados os pontos de evolução do projeto e é feita a conclusão formal das etapas. É isto simples: qualquer um que tenha o poder para rejeitar ou para exigir revisão dos produtos do projeto depois de completos deveria ter exigido sua revisão durante sua construção, antes de sua conclusão.
O sucesso do projeto está relacionado à análise completa das necessidades e dos produtos. Nossa experiência nos mostra que quando um projeto documenta claramente as necessidades e os produtos resultantes, as chances de sucesso do projeto são muito maiores. Por outro lado, quando essas expectativas não são claramente documentadas, torna-se muito difícil evitar mudanças de escopo e desperdícios de recursos. O gerente deveria insistir que as necessidades de negócio do projeto sejam documentados claramente antes de iniciar a consumir recursos organizacionais.
Os gerentes de projeto devem lutar por tempo para fazer direito de coisas. Em nosso trabalho com gerentes de projeto nós ouvimos freqüentemente esta reclamação: “Parece que sempre temos tempo para refazer o projeto; Eu só queria poder ter o tempo necessário para fazer as coisas direito da primeira vez!” Os projetos devem ter tempo suficiente para "fazer direito da primeira vez." E os gerentes de projeto devem lutar para demonstrar aos patrocinadores e gerentes superiores por que é necessário e como o tempo gasto resultará na qualidade dos resultados.
A responsabilidade de gerente de projeto deve ser acompanhada da autoridade equivalente. Não basta ser o responsável pelos resultados do projeto; os gerentes de projeto devem negociar e obter autoridade suficiente para executar suas responsabilidades. Especificamente, gerentes devem ter a autoridade para adquirir e coordenar recursos, pedir e receber cooperação de superiores, enfim, tomar decisões apropriadas e implementa-las.
Os patrocinadores do projeto devem ser participantes ativos. A maioria de patrocinadores de projeto exigem legalmente a autoridade para aprovar os resultados de projetos, integralemnte ou em parte. Junto com essa autoridade, vem a responsabilidade de ser um participante ativo no início das fases (ajudando a definir os resultados), nas revisões (mantendo ou mudando pontos do projeto), e, é claro, na entrega dos resultados. Além disso, os patrocinadores podem ter papel importante em auxiliar o gerente no acesso aos membros da alta direção da corporação.
O gerente deve vender bem o seu projeto Existem ocasiões em que o gerente de projeto deve trabalhar como um vendedor para manter o compromisso com os patrocinadores. Com os planos de projeto em mão, o gerente de projeto precisa lembrar periodicamente sua equipe sobre as necessidades de negócio e que sua contribuição é essenciais para atender a essas demandas.
O gerente de projeto deve adquirir as melhores pessoas e então fazer o que for preciso para manter o lixo fora de seu caminho. Adquirindo as melhores pessoas – as mais qualificadas, as mais experimentadas, as melhores qualificadas – o gerente de projeto pode compensar a escassez de tempo ou dinheiro ou outras restrições de projeto. Os gerentes de projeto devem servir como um advogado para esses membros valiosos, ajudando a protege-los de interrupções e ajudando-os a adquirir as ferramentas e condições de trabalho necessárias para aplicar seus talentos.
A alta direção deve determinar ativamente as prioridades. Não é incomum que um gerente desempenhe diversos papéis em diferentes equipes de projeto ao mesmo tempo. Em última instância, pode chegar uma ocasião em que os recursos são usados além de seus limites e existam simplesmente mais projetos que a capacidade da equipe de completá-los a contento. Em resposta, algumas organizações estabeleceram um Escritório de Projeto com gerentes de todos os departamentos para agir como um facilitador para projetos. O Escritório de Projeto revisa a missão e estratégias globais da organização, estabelece critérios para seleção de projetos, acompanha a carga de trabalho dos recursos, e determina que projetos são de prioridade alta o bastante para ser aprovado. A alta direção fornece a liderança necessária para prevenir o travamento de equipes em múltiplos projetos.
Fonte: Gerenciando Projetos (www.malima.com.br)
Planejamento é tudo - e é contínuo. Em um coisa todos os textos e autoridades de Gerenciamento de Projetos concordam: A atividade única mais importante que gerentes de projeto tomam parte é o planejamento - planos detalhados, sistemáticos e envolvendo a equipe são o alicerce para o sucesso do projeto. E quando os eventos do mundo real conspiram contra seu plano, o gerente de projeto deve fazer um novo plano refletindo essas mudanças. Então planejamento e replanejamento devem ser o estilo de vida para gerentes de projeto.
Os gerentes de projeto devem sentir e transmitir para a equipe um senso de urgência. Porque projetos são empenhos finitos com tempo, orçamento, e outros recursos limitados, eles devem avançar continuamente rumo à conclusão. Já que a maioria de membros de equipe tem outras prioridades, cabe ao gerente de projeto manter sua atenção nas metas e prazos finais do projeto. Reuniões periódicas de acompanhamento e alertas são essenciais para corrigir os desvios tão logo seja identificados.
Os projetos bem sucedidos usam um método de trabalho estabelecido. Nós sabemos o que funciona. Os modelos como o ISD e outros descrito neste texto podem ajudar a assegurar que os padrões profissionais e as melhores práticas sejam aplicadas em nossos planos de projeto. Esses modelos não servem somente para garantir a qualidade do projeto, eles ajudam a minimizar retrabalho e consequentemente otimizar o tempo do gerente de projetos. Então quando pressões de tempo ou orçamento parecem encorajar pequenos cortes, cabe ao gerente de projeto identificar e defender o melhor ciclo da vida de projeto para o trabalho.
Todos os resultados e todas as atividades do projeto devem ser visualizados e comunicados com detalhes vívidos. Em resumo, o gerente de projeto e a equipe de projeto devem se apressar em criar um retrato mental das metas, objetivos e resultados do projeto de forma que todo esforço é focado na mesma direção. Evite descrições vagas a todo custo: defina, explique, exemplifique, prototipe, ponha em termos claros e certifique-se de que todo mundo concorda com isso.
Deliverables devem evoluir gradualmente, em refinamentos sucessivas. Pode ser simplesmente caro demais e arriscado demais ter que refazer um deliverable do projeto por erro ou omissão. Construa um pouco de cada vez, obtenha revisões e aprovações com ampliação, e mantenha uma evolução controlada.
Os projetos exigem aprovações e critérios de conclusão claramente definidos pelos patrocinadores. Ao final de uma etapa do projeto o Gerente deve ter uma reunião formal para entregar os deliverables de acordo com os critérios de conclusão de fase. É fundamental que os patrocinadores do projeto participem dessa reunião em que são apresentados os pontos de evolução do projeto e é feita a conclusão formal das etapas. É isto simples: qualquer um que tenha o poder para rejeitar ou para exigir revisão dos produtos do projeto depois de completos deveria ter exigido sua revisão durante sua construção, antes de sua conclusão.
O sucesso do projeto está relacionado à análise completa das necessidades e dos produtos. Nossa experiência nos mostra que quando um projeto documenta claramente as necessidades e os produtos resultantes, as chances de sucesso do projeto são muito maiores. Por outro lado, quando essas expectativas não são claramente documentadas, torna-se muito difícil evitar mudanças de escopo e desperdícios de recursos. O gerente deveria insistir que as necessidades de negócio do projeto sejam documentados claramente antes de iniciar a consumir recursos organizacionais.
Os gerentes de projeto devem lutar por tempo para fazer direito de coisas. Em nosso trabalho com gerentes de projeto nós ouvimos freqüentemente esta reclamação: “Parece que sempre temos tempo para refazer o projeto; Eu só queria poder ter o tempo necessário para fazer as coisas direito da primeira vez!” Os projetos devem ter tempo suficiente para "fazer direito da primeira vez." E os gerentes de projeto devem lutar para demonstrar aos patrocinadores e gerentes superiores por que é necessário e como o tempo gasto resultará na qualidade dos resultados.
A responsabilidade de gerente de projeto deve ser acompanhada da autoridade equivalente. Não basta ser o responsável pelos resultados do projeto; os gerentes de projeto devem negociar e obter autoridade suficiente para executar suas responsabilidades. Especificamente, gerentes devem ter a autoridade para adquirir e coordenar recursos, pedir e receber cooperação de superiores, enfim, tomar decisões apropriadas e implementa-las.
Os patrocinadores do projeto devem ser participantes ativos. A maioria de patrocinadores de projeto exigem legalmente a autoridade para aprovar os resultados de projetos, integralemnte ou em parte. Junto com essa autoridade, vem a responsabilidade de ser um participante ativo no início das fases (ajudando a definir os resultados), nas revisões (mantendo ou mudando pontos do projeto), e, é claro, na entrega dos resultados. Além disso, os patrocinadores podem ter papel importante em auxiliar o gerente no acesso aos membros da alta direção da corporação.
O gerente deve vender bem o seu projeto Existem ocasiões em que o gerente de projeto deve trabalhar como um vendedor para manter o compromisso com os patrocinadores. Com os planos de projeto em mão, o gerente de projeto precisa lembrar periodicamente sua equipe sobre as necessidades de negócio e que sua contribuição é essenciais para atender a essas demandas.
O gerente de projeto deve adquirir as melhores pessoas e então fazer o que for preciso para manter o lixo fora de seu caminho. Adquirindo as melhores pessoas – as mais qualificadas, as mais experimentadas, as melhores qualificadas – o gerente de projeto pode compensar a escassez de tempo ou dinheiro ou outras restrições de projeto. Os gerentes de projeto devem servir como um advogado para esses membros valiosos, ajudando a protege-los de interrupções e ajudando-os a adquirir as ferramentas e condições de trabalho necessárias para aplicar seus talentos.
A alta direção deve determinar ativamente as prioridades. Não é incomum que um gerente desempenhe diversos papéis em diferentes equipes de projeto ao mesmo tempo. Em última instância, pode chegar uma ocasião em que os recursos são usados além de seus limites e existam simplesmente mais projetos que a capacidade da equipe de completá-los a contento. Em resposta, algumas organizações estabeleceram um Escritório de Projeto com gerentes de todos os departamentos para agir como um facilitador para projetos. O Escritório de Projeto revisa a missão e estratégias globais da organização, estabelece critérios para seleção de projetos, acompanha a carga de trabalho dos recursos, e determina que projetos são de prioridade alta o bastante para ser aprovado. A alta direção fornece a liderança necessária para prevenir o travamento de equipes em múltiplos projetos.
Fonte: Gerenciando Projetos (www.malima.com.br)
O que fazer para salvar o projeto se o cronograma está atrasado?
Se você percebeu o atraso no cronograma do projeto, não se desespere. Segundo Capers Jones (Assessment Control on Software Risks), alguns índices devem ser considerados:
• 70% dos grandes projetos sofrem de instabilidade de requisitos;
• Pelo menos 50% dos projetos são executados com níveis de produtividade abaixo do normal;
• Pelo menos 25% dos softwares de prateleira e 50% dos feitos por encomenda apresentam mais defeitos do que o razoável;
• Pelo menos 50% dos grandes projetos de software estouram seu orçamento e prazo.
Não se deve, porém, perder mais tempo com justificativas nem tão pouco considerar que o atraso não precisa de uma tratativa imediata. O primeiro passo é analisar a situação. É fundamental descobrir as causas do desvio. Seguir adiante sem uma criteriosa análise poderá aumentar alguns fatores de risco a ponto de se tornar impraticável seu gerenciamento.
Discuta os pontos críticos com um observador externo.
Um observador externo (outro gerente de projeto) poderá avaliar a situação de forma neutra e perceber detalhes que não tenham sido considerados. É natural, em situações de crise, que os membros do grupo hajam de forma tendenciosa, deixando que pequenos detalhes causem grandes problemas. Não hesite em pedir ajuda.
O que levou ao desvio?
Identificar corretamente as causas do desvio contribuirá significativamente para a negociação e o realinhamento do projeto aos seus objetivos iniciais.
As mais prováveis causas de desvio estão citadas abaixo:
• Desconhecimento ou desconsideração da importância de um ou mais interessados do projeto;
• Ausência de padrões e/ou métodos, desde o gerenciamento até a implementação do projeto;
• Requisitos mal definidos, entendidos ou implementados;
• Estimativas falhas ou excesso de otimismo durante a estimativa;
• Tentativa de implementação de todos os requisitos que surgem no decorrer do projeto sem que seja feita uma renegociação do prazo inicial;
• Aceitação por parte do gerente do projeto de um cronograma imposto e virtualmente impossível de ser cumprido;
• Aceitação por parte do gerente do projeto de uma diminuição de prazo sem a contrapartida de aumento dos recursos;
• Mudanças constantes das prioridades por parte dos interessados;
• Ausência de um estudo detalhado e planejamento de riscos;
• Mudanças constantes na equipe de projeto.
• Inexperiência da equipe em relação às metodologias ou tecnologias utilizadas no projeto;
• Utilização de tecnologias novas, sujeitas a prováveis falhas futuras não catalogadas.
Ataque o problema por partes e retome o controle aos poucos.
Tratar o conjunto de problemas identificados deve ser considerado um novo projeto.
Decomponha o problema em partes mensuráveis, atribua um responsável, desenvolva uma estratégia para abordá-las e crie um novo cronograma onde todas as tarefas estejam especificadas como “têm de ser feito” (essenciais) ou “deveria der feito” (serão excluídas do escopo) ou “poderia ser feito” (poderão ser incluídas no escopo), levando-se em conta as expectativas do cliente.
Comunique-se. Negocie.
Segundo a Metodologia PMBOK, a comunicação é uma ferramenta que deve ser utilizada em 90% do tempo do gerente de projetos e a negociação é uma das habilidades indispensáveis aos gerentes de projetos. Em momentos de crise elas serão ainda mais importantes. Novos prazos, custos, mudanças de escopo, características do produto deverão ser renegociados, ou seja, o projeto deverá ser tente redimensionado conforme a nova capacidade de trabalho. Vale lembrar que produtos feitos sob pressão de prazos poderão ter sua qualidade comprometida.
Nesse momento, os riscos precisam ser minimizados através de negociações vantajosas para ambos os lados, sendo fundamental manter o cronograma proposto e a distribuição das tarefas nas três categorias. A nova proposta deverá ser clara e viável de forma que o cliente acredite que as tarefas eleitas serão realmente implementadas no prazo e custo combinados e com a qualidade desejada.
Todos os aspectos deverão ser considerados, pois uma nova negociação será muito difícil, ou quase impossível.
Outra opção seria dividir o projeto em módulos funcionais onde que possam satisfazer o cliente dando um novo fôlego à equipe do projeto para que possam implementar as entregas posteriores com certa tranqüilidade.
É importante também rever a lista de interessados (stakeholders) do projeto para que sejam envolvidos todos aqueles que têm relação direta ou indireta com o projeto, pois, gerenciar interesses e interessados com expectativas diferentes é uma tarefa que requer muito conhecimento sobre esse conjunto de variáveis.
Vale lembrar...
Todos os índices devem ser revistos periodicamente de forma a se avaliar sua adequação ao projeto. A modelagem e o desenho do projeto deverão ser validados e, se necessário, completamente substituídos caso seja verificado que aumentarão os esforço de implementação.
De nada adianta a equipe trabalhar horas e horas a fio, após o horário e durante o final de semana no início do cronograma. O stress causado na equipe pode comprometer o adiantamento do prazo conseguido, pois o cansaço dos membros da equipe pode vir a gerar uma quantidade excessiva de falhas, que causarão o dobro de retrabalho nas próximas semanas. Planeje o esforço dobrado para sua equipe para os momentos finais de cada marco no cronograma, intercalando o esforço de cada um com períodos de descanso alternados entre os membros.
Analise a equipe inicial do projeto. Várias falhas no projeto inicial podem estar relacionadas com o desempenho da equipe ou do gerente em relação a ela. Não reinicie o projeto sem a certeza do comprometimento de todos. Caso venha a notar qualquer problema em relação aos membros da equipe, negocie as substituições necessárias antes do início do projeto. Faça essa verificação, na medida do possível, em conjunto com a equipe, deixando “às claras” toda a situação. A equipe deve ver em você um líder; deve confiar na sua lealdade para com todos. Caso contrário, não haverá comprometimento. Isto quer dizer que você deve não só se preocupar com o quanto a equipe pode contribuir no projeto, mas também com o quanto você pode contribuir com a equipe.
O gerente que vivencia os problemas de sua equipe está trabalhando para o sucesso do projeto.
Fonte: O Blog da Gerência de Projetos
• 70% dos grandes projetos sofrem de instabilidade de requisitos;
• Pelo menos 50% dos projetos são executados com níveis de produtividade abaixo do normal;
• Pelo menos 25% dos softwares de prateleira e 50% dos feitos por encomenda apresentam mais defeitos do que o razoável;
• Pelo menos 50% dos grandes projetos de software estouram seu orçamento e prazo.
Não se deve, porém, perder mais tempo com justificativas nem tão pouco considerar que o atraso não precisa de uma tratativa imediata. O primeiro passo é analisar a situação. É fundamental descobrir as causas do desvio. Seguir adiante sem uma criteriosa análise poderá aumentar alguns fatores de risco a ponto de se tornar impraticável seu gerenciamento.
Discuta os pontos críticos com um observador externo.
Um observador externo (outro gerente de projeto) poderá avaliar a situação de forma neutra e perceber detalhes que não tenham sido considerados. É natural, em situações de crise, que os membros do grupo hajam de forma tendenciosa, deixando que pequenos detalhes causem grandes problemas. Não hesite em pedir ajuda.
O que levou ao desvio?
Identificar corretamente as causas do desvio contribuirá significativamente para a negociação e o realinhamento do projeto aos seus objetivos iniciais.
As mais prováveis causas de desvio estão citadas abaixo:
• Desconhecimento ou desconsideração da importância de um ou mais interessados do projeto;
• Ausência de padrões e/ou métodos, desde o gerenciamento até a implementação do projeto;
• Requisitos mal definidos, entendidos ou implementados;
• Estimativas falhas ou excesso de otimismo durante a estimativa;
• Tentativa de implementação de todos os requisitos que surgem no decorrer do projeto sem que seja feita uma renegociação do prazo inicial;
• Aceitação por parte do gerente do projeto de um cronograma imposto e virtualmente impossível de ser cumprido;
• Aceitação por parte do gerente do projeto de uma diminuição de prazo sem a contrapartida de aumento dos recursos;
• Mudanças constantes das prioridades por parte dos interessados;
• Ausência de um estudo detalhado e planejamento de riscos;
• Mudanças constantes na equipe de projeto.
• Inexperiência da equipe em relação às metodologias ou tecnologias utilizadas no projeto;
• Utilização de tecnologias novas, sujeitas a prováveis falhas futuras não catalogadas.
Ataque o problema por partes e retome o controle aos poucos.
Tratar o conjunto de problemas identificados deve ser considerado um novo projeto.
Decomponha o problema em partes mensuráveis, atribua um responsável, desenvolva uma estratégia para abordá-las e crie um novo cronograma onde todas as tarefas estejam especificadas como “têm de ser feito” (essenciais) ou “deveria der feito” (serão excluídas do escopo) ou “poderia ser feito” (poderão ser incluídas no escopo), levando-se em conta as expectativas do cliente.
Comunique-se. Negocie.
Segundo a Metodologia PMBOK, a comunicação é uma ferramenta que deve ser utilizada em 90% do tempo do gerente de projetos e a negociação é uma das habilidades indispensáveis aos gerentes de projetos. Em momentos de crise elas serão ainda mais importantes. Novos prazos, custos, mudanças de escopo, características do produto deverão ser renegociados, ou seja, o projeto deverá ser tente redimensionado conforme a nova capacidade de trabalho. Vale lembrar que produtos feitos sob pressão de prazos poderão ter sua qualidade comprometida.
Nesse momento, os riscos precisam ser minimizados através de negociações vantajosas para ambos os lados, sendo fundamental manter o cronograma proposto e a distribuição das tarefas nas três categorias. A nova proposta deverá ser clara e viável de forma que o cliente acredite que as tarefas eleitas serão realmente implementadas no prazo e custo combinados e com a qualidade desejada.
Todos os aspectos deverão ser considerados, pois uma nova negociação será muito difícil, ou quase impossível.
Outra opção seria dividir o projeto em módulos funcionais onde que possam satisfazer o cliente dando um novo fôlego à equipe do projeto para que possam implementar as entregas posteriores com certa tranqüilidade.
É importante também rever a lista de interessados (stakeholders) do projeto para que sejam envolvidos todos aqueles que têm relação direta ou indireta com o projeto, pois, gerenciar interesses e interessados com expectativas diferentes é uma tarefa que requer muito conhecimento sobre esse conjunto de variáveis.
Vale lembrar...
Todos os índices devem ser revistos periodicamente de forma a se avaliar sua adequação ao projeto. A modelagem e o desenho do projeto deverão ser validados e, se necessário, completamente substituídos caso seja verificado que aumentarão os esforço de implementação.
De nada adianta a equipe trabalhar horas e horas a fio, após o horário e durante o final de semana no início do cronograma. O stress causado na equipe pode comprometer o adiantamento do prazo conseguido, pois o cansaço dos membros da equipe pode vir a gerar uma quantidade excessiva de falhas, que causarão o dobro de retrabalho nas próximas semanas. Planeje o esforço dobrado para sua equipe para os momentos finais de cada marco no cronograma, intercalando o esforço de cada um com períodos de descanso alternados entre os membros.
Analise a equipe inicial do projeto. Várias falhas no projeto inicial podem estar relacionadas com o desempenho da equipe ou do gerente em relação a ela. Não reinicie o projeto sem a certeza do comprometimento de todos. Caso venha a notar qualquer problema em relação aos membros da equipe, negocie as substituições necessárias antes do início do projeto. Faça essa verificação, na medida do possível, em conjunto com a equipe, deixando “às claras” toda a situação. A equipe deve ver em você um líder; deve confiar na sua lealdade para com todos. Caso contrário, não haverá comprometimento. Isto quer dizer que você deve não só se preocupar com o quanto a equipe pode contribuir no projeto, mas também com o quanto você pode contribuir com a equipe.
O gerente que vivencia os problemas de sua equipe está trabalhando para o sucesso do projeto.
Fonte: O Blog da Gerência de Projetos
Problemas Típicos em Projetos
Podem ser considerados problemas típicos na implementação de projetos:
• Complexidade do Projeto;
• Gerenciamento ineficiente ou amador;
• Excesso de conflitos entre membros da equipe de projeto;
• Falta de planejamento ou planejamento deficiente;
• Objetivos mal definidos;
• Excesso de alteração de escopo;
• Incertezas e riscos;
• Mudanças tecnológicas;
• Estimativas de prazo e custo mal elaboradas; e
• Falta de controle ou controle ineficiente.
Quando esses problemas não são gerenciados e tratados adequadamente, podem tornar-se sérios obstáculos ao sucesso do projeto.
"Quando um projeto é bem estruturado e se desenvolve tranqüilamente, seus desafios podem ser estimulantes e prazerosos. Mas sendo mal definido ou mal gerenciado pode se tornar um pesadelo para todos os envolvidos, resultar em desastre financeiro e prejudicar muitas carreiras promissoras." (Ralph Keeling).
No Brasil, encontramos dificuldades ainda maiores diante desses problemas típicos, muito em virtude dos seguintes aspectos:
- Ausência de padronização nos processos;
- Dificuldade de mudança cultural quando novos processos são propostos ou implantados;
- Não há cultura de registro histórico de lições aprendidas em projetos;
- Não existe estimativa de gastos ou a estimativa é mal feita;
- O processo de lançamento de projetos é demorado e mal planejado;
- Falta integração entre as áreas de Marketing e Logística com a Gerência de Projetos;
- Não há um formato e um padrão de documentos e manuais;
- Ausência de um meio comum de veiculação e armazenagem das informações (intranet, banco de dados, etc.);
- Falta de conhecimento da existência de boas práticas em Gerenciamento de Projetos.
É importante ressaltar que projetos não são exclusividade das áreas de Engenharia e TI. Áreas como Publicidade, Pedagogia e Financeira também implementam projetos e sofrem dos mesmos problemas.
Fonte: Portal GP
• Complexidade do Projeto;
• Gerenciamento ineficiente ou amador;
• Excesso de conflitos entre membros da equipe de projeto;
• Falta de planejamento ou planejamento deficiente;
• Objetivos mal definidos;
• Excesso de alteração de escopo;
• Incertezas e riscos;
• Mudanças tecnológicas;
• Estimativas de prazo e custo mal elaboradas; e
• Falta de controle ou controle ineficiente.
Quando esses problemas não são gerenciados e tratados adequadamente, podem tornar-se sérios obstáculos ao sucesso do projeto.
"Quando um projeto é bem estruturado e se desenvolve tranqüilamente, seus desafios podem ser estimulantes e prazerosos. Mas sendo mal definido ou mal gerenciado pode se tornar um pesadelo para todos os envolvidos, resultar em desastre financeiro e prejudicar muitas carreiras promissoras." (Ralph Keeling).
No Brasil, encontramos dificuldades ainda maiores diante desses problemas típicos, muito em virtude dos seguintes aspectos:
- Ausência de padronização nos processos;
- Dificuldade de mudança cultural quando novos processos são propostos ou implantados;
- Não há cultura de registro histórico de lições aprendidas em projetos;
- Não existe estimativa de gastos ou a estimativa é mal feita;
- O processo de lançamento de projetos é demorado e mal planejado;
- Falta integração entre as áreas de Marketing e Logística com a Gerência de Projetos;
- Não há um formato e um padrão de documentos e manuais;
- Ausência de um meio comum de veiculação e armazenagem das informações (intranet, banco de dados, etc.);
- Falta de conhecimento da existência de boas práticas em Gerenciamento de Projetos.
É importante ressaltar que projetos não são exclusividade das áreas de Engenharia e TI. Áreas como Publicidade, Pedagogia e Financeira também implementam projetos e sofrem dos mesmos problemas.
Fonte: Portal GP
Qual é melhor, PRINCE2 ou PMBOK Guide?
PRINCE2 é melhor que o PMBOK? A certificação PMP é mais difícil de ser obtida do que a certificação PRINCE2? Qual das certificações devo tirar primeiro? Vale a pena ter as duas certificações?
O assunto certificação merece um destaque à parte e, por esta razão, escreverei a respeito em uma das séries do PRINCE2 sem mistério.
Antes de ajudá-los a responder a pergunta deste artigo, segue uma breve descrição das duas abordagens.
A Guide to the Project Management Body of Knowledge (PMBOK Guide), como a tradução do próprio nome diz, é um guia de conhecimentos para o gerenciamento de projetos. O PMBOK Guide é de propriedade do PMI (Project Management Insitute) e sua primeira edição foi lançada no ano de 1996.
O Project IN Controlled Enviroment (PRINCE2) é uma metodologia para o gerenciamento de projetos. Este método é bastante difundido na Europa e está começando a ser utilizado, de forma mais expressiva, aqui no Brasil. PRINCE2 é uma marca registrada do OGC (The Office Government Commerce) e teve seu primeiro lançamento em 1996. Nas próximas edições da série PRINCE2 sem mistérios, vocês terão oportunidade de saber um pouco mais sobre esta metodologia.
A diferença básica entre PMBOK Guide e PRINCE2 é que enquanto o primeiro é uma base de conhecimentos e boas práticas de gerenciamento de projetos, o segundo é uma abordagem estruturada, com processos, papéis e responsabilidades bem definidos, que orienta o gerente e time do projeto na condução do projeto. O PMBOK Guide mostra “o que” é necessário fazer e o PRINCE2 mostra “como” fazer.
E então, qual o melhor, PMBOK Guide ou PRINCE2?
Tanto o PMBOK Guide quanto o PRINCE2 tem suas vantagens e, apesar das diferenças, não tem como responder qual deles é o melhor. O mais correto é entender que ambos são complementares e que, se utilizados em conjunto, é possível adquirir vantagens através da obtenção do que há de melhor nestas duas abordagens referências de gerenciamento de projetos.
O assunto certificação merece um destaque à parte e, por esta razão, escreverei a respeito em uma das séries do PRINCE2 sem mistério.
Antes de ajudá-los a responder a pergunta deste artigo, segue uma breve descrição das duas abordagens.
A Guide to the Project Management Body of Knowledge (PMBOK Guide), como a tradução do próprio nome diz, é um guia de conhecimentos para o gerenciamento de projetos. O PMBOK Guide é de propriedade do PMI (Project Management Insitute) e sua primeira edição foi lançada no ano de 1996.
O Project IN Controlled Enviroment (PRINCE2) é uma metodologia para o gerenciamento de projetos. Este método é bastante difundido na Europa e está começando a ser utilizado, de forma mais expressiva, aqui no Brasil. PRINCE2 é uma marca registrada do OGC (The Office Government Commerce) e teve seu primeiro lançamento em 1996. Nas próximas edições da série PRINCE2 sem mistérios, vocês terão oportunidade de saber um pouco mais sobre esta metodologia.
A diferença básica entre PMBOK Guide e PRINCE2 é que enquanto o primeiro é uma base de conhecimentos e boas práticas de gerenciamento de projetos, o segundo é uma abordagem estruturada, com processos, papéis e responsabilidades bem definidos, que orienta o gerente e time do projeto na condução do projeto. O PMBOK Guide mostra “o que” é necessário fazer e o PRINCE2 mostra “como” fazer.
E então, qual o melhor, PMBOK Guide ou PRINCE2?
Tanto o PMBOK Guide quanto o PRINCE2 tem suas vantagens e, apesar das diferenças, não tem como responder qual deles é o melhor. O mais correto é entender que ambos são complementares e que, se utilizados em conjunto, é possível adquirir vantagens através da obtenção do que há de melhor nestas duas abordagens referências de gerenciamento de projetos.
PRINCE2 ® is a registered trade mark of OGC
PMBOK® Guide is a registred mark of PMI
Por Roberiton Ribeiro, 29 de Março de 2010
quarta-feira, 20 de outubro de 2010
Gerente de Projetos: Competências Técnicas ou Interpessoais?
Texto extraído do blog http://klingermenezes.wordpress.com
Autor: Klinger Menezes, PMP under Human Resources, Project Management
No mundo corporativo muito se fala em gerenciar projetos, e com isso, vem a pergunta sobre quais as competências importantes para um gerente de projetos.
Muitos falam que para gerenciar um projeto, não é necessário conhecer o negócio; O Importante mesmo é conhecer e ter experiência nas áreas de conhecimento, processos e metodologia em gerência de projetos.
Mas até que ponto isso pode ser considerado verdade? Apenas o conhecimento técnico da metodologia é suficiente para tornar um gerente de projetos competente e garantir o sucesso deste projeto? Bom, “garantir” talvez seja um pouco de exagero de minha parte, como já foi visto anteriormente, aumentar a probabilidade de sucesso seria mais adequado.
Assim outra pergunta acaba sempre nos perturbando. Qual competência é mais importante para a contratação de um gerente projetos: o que tem profundos conhecimentos técnicos na metodologia ou aquele que tem maior experiência e habilidades interpessoais?
Neste pequeno artigo, não tenho a pretensão de medir as diversas variáveis e expor uma resposta decisiva. Diante tantas variáveis, por exemplo, tipos e portes de projetos, seria no mínimo irresponsável definir um padrão a ser seguido. A idéia é fazer com que o leitor, através das considerações expostas, reflita e analise os melhores critérios para cada caso.
Claro que o mais lógico seria procurar um gerente de projetos que possuísse as competências de forma equilibrada, tanto na área técnica como na área interpessoal.
Hoje, algumas habilidades passaram a ser consideradas importantes, não mais consideradas apenas como desejáveis. São elas:
- Relacionamento interpessoal
- Gestão de conflitos
- Inteligência emocional
- Liderança
- Comunicação
- Negociação
- Coaching e Mentoring
O próprio PMI passou a valorizar de forma mais enfática estas características ligadas à gerência de stakeholders, sugerindo uma maior humanização do gerenciamento de projetos.
É curioso perceber o quanto a profissão tem evoluído, tanto em quantidade de interessados em exercê-la e como o conhecimento em si tem amadurecido, onde o perfil do profissional, em sua maioria, busca a atualização e aperfeiçoamento. Acredito não ser possível ignorar o valor do conhecimento técnico e metodológico, muito menos sua utilização, mas devemos considerar e reconhecer cada vez mais quem está por trás de todos os projetos, as pessoas.
A função do Gerente de Projetos de Software
| Texto extraído do site http://www.netopaim.eng.br |
Superficialmente, a função de um gerente de projetos deveria ser fácil de descrever. Mas o desafio de entender as funções e as responsabilidades de gerenciamento de projetos é diferente de empresa para empresa. Definição Geral
Em geral, o gerente do projeto é responsável pelo sucesso total do projeto. Em algumas empresas, esta pessoa pode ser chamada "Coordenador do Projeto", ou "Líder da Equipe". Contudo, o aspecto chave é que a pessoa é responsável pelo sucesso do projeto.
Responsabilidade pelos Processos
O que transforma um projeto em um sucesso? Se o gerente do projeto seguir uma metodologia de gerenciamento de projetos, como o PMI®, ou outra semelhante, ele deverá primeiramente definir o projeto e construir o cronograma e o orçamento. É aí que as responsabilidades do gerente do projeto iniciam. Se o projeto iniciar e, mais tarde, o gerente do projeto descobrir que o escopo não está bem definido, a responsabilidade será toda do gerente do projeto. Se o seu projeto estiver utilizando um cronograma inadequado, a responsabilidade também será toda do gerente do projeto.
O trabalho de definição do projeto significa que você entendeu e recebeu a total concordância sobre os objetivos, escopo, risco, abordagem, orçamento, etc. Isto também inclui definir ou adotar os procedimentos específicos de gerenciamento de projeto que serão utilizados para gerenciar o projeto.
Isto não significa que o gerente do projeto necessita fazer todo este trabalho sozinho. Pode haver uma equipe inteira auxiliando na criação do documento "Definição do Projeto" e do cronograma. Contudo, se algo sair errado, a responsabilidade será toda do gerente do projeto.
Uma vez iniciado o projeto, o gerente do projeto deve gerenciar e controlar o trabalho, incluindo:
* O gerenciamento do cronograma para assegurar-se que o trabalho foi atribuído aos membros da equipe e que o mesmo será entregue dentro do orçamento e do prazo acordado.
* A identificação, a documentação, o gerenciamento e a resolução das Incidências problemáticas.
* O gerenciamento pró-ativo do escopo para assegurar-se que apenas o que foi aprovado será entregue, exceto no caso das mudanças serem aprovadas pelo processo de gerenciamento das mudanças do escopo.
* A disseminação pró-ativa das informações do projeto a todas as partes interessadas.
* A identificação, o gerenciamento e a mitigação dos riscos do projeto.
* A execução de processos de garantia e de controle da qualidade para assegurar uma solução com um nível de qualidade aceitável.
* A definição e a coleta de métricas para dar uma idéia de como o projeto está progredindo e se as entregas produzidas são aceitáveis.
Isso não significa que o gerente do projeto faça tudo isso fisicamente, mas ele deve certificar-se de que isso realmente está ocorrendo. Se o projeto tiver problemas, ou seu escopo avançar lentamente, ou enfrentar riscos, ou não estiver estabelecendo as expectativas corretamente, o gerente do projeto será a pessoa responsável por isso.
Para gerenciar os processos de gerenciamento de um projeto, uma pessoa deve ser bem organizada, possuir uma grande capacidade de acompanhamento, ser orientada ao processo, ser capaz de desempenhar múltiplas tarefas, ter um processo de raciocínio lógico, ser capaz de determinar as causas principais, ter uma boa capacidade de análise, ser um bom avaliador e gerente do orçamento, e ter autodisciplina.
Responsabilidade pelas Pessoas
Além das habilidades relacionadas aos processos, um gerente de projetos deve ter uma boa capacidade no gerenciamento de pessoas. Isto inclui:
* Ter disciplina e capacidade de gerenciamento geral, para certificar-se de que as pessoas seguem os processos e procedimentos padrão.
* Estabelecer habilidades de liderança para fazer com que a equipe siga as suas instruções. Liderança significa comunicar uma visão e fazer com que a equipe a aceite e lute para chegar lá com você.
* Estabelecer expectativas razoáveis, desafiadoras e claras para as pessoas, e fazer com que elas se sintam responsáveis pelo atendimento das expectativas. Isto inclui fornecer um bom feedback sobre o desempenho das mesmas.
* Habilidades para criar uma equipe, de modo que as pessoas trabalhem bem em conjunto, e se sintam motivadas para trabalharem duramente pela causa do projeto e pelos outros integrantes da equipe. Quanto maior for sua equipe, e mais longo o projeto, mais importante se torna ter boas habilidades para criar uma equipe.
* Habilidades pró-ativas verbais e escritas de comunicador, incluindo boas e ativas habilidades de escutar.
Novamente, você é responsável pelo sucesso do projeto. Se a equipe tiver com a moral baixa e estiver perdendo prazos, você deverá tentar resolver isso. Se os membros da equipe não entenderem exatamente o que necessitam fazer e quando devem fazê-lo, o gerente do projeto será o responsável por isso.
Múltiplas Funções
Múltiplas Funções
Dependendo do tamanho e da complexidade do projeto, o gerente do projeto poderá assumir outras responsabilidades além do gerenciamento do trabalho. Por exemplo, o gerente do projeto poderá auxiliar com a coleta das necessidades do negócio, ou poderá auxiliar no projeto de um sistema de gerenciamento de banco de dados, ou redigir a documentação do projeto. O gerenciamento do projeto é uma função especial que uma pessoa deve preencher, mesmo se a pessoa estiver trabalhando também em outras funções.
Por exemplo, um gerente de projeto pode distribuir seu tempo da seguinte maneira: gerenciar o projeto durante 45% de seu tempo, executar a função de análise do negócio 25%, trabalhar no design 15% e escrever a documentação durante 15% do tempo. Isto não significa que uma das responsabilidades da função do gerente do projeto seja gastar 15% de seu tempo no design. Ao invés disso, significa apenas que o projeto não é grande o bastante para necessitar de um gerente de projeto em tempo integral. O gerente do projeto gasta o resto de seu tempo em outras funções do projeto tais como, Analista de Negócios, Projetista, Redator Técnico, etc. Dependendo do tamanho de seus projetos, e da maneira como a sua empresa é organizada, o tempo de um gerente de projetos pode ser alocado seguindo uma dessas três formas:
* Pode ter uma função com tempo integral em um projeto grande.
* Pode ter responsabilidades de gerenciamento de projeto para múltiplos projetos, ocupando cada um deles tempo inferior ao tempo integral, mas sua combinação preenche uma função com tempo integral.
* Pode preencher múltiplas funções, sendo exigido para cada uma delas um determinado nível de habilidade e de responsabilidade. Em um projeto, por exemplo, pode ser, ao mesmo tempo, o gerente do projeto e um dos analistas.
fonte: TenStep®
Assinar:
Comentários (Atom)