Os 7 passos do gerenciamento de projetos

05-06-2014 23:26

Os 7 passos do gerenciamento de projetos

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:

 

 

http://www.microsoft.com/brasil/msdn/images/Colunas/tab_carreira.jpg

 

 

Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, interdependê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:

http://www.microsoft.com/brasil/msdn/images/Colunas/tab1_carreira.jpg

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 (fernando@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 (www.advancemarketing.com.br)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

O Dogma e o Ateísmo

Postado por Leandro Santoro

Calma, não tem nada a ver com religião. Achei o título apropriado para fazer uma analogia interessante – de pessoas que acreditam que a aplicação de metodologias, modelos, padronizações, e boas práticas é o caminho para o sucesso(o dogmático) e outras que não enxergam nenhum valor prático nisso e que essas coisas só atrapalham seu trabalho(o ateu).

Vamos começar falando sobre o “Ateu”. Ele é presente em todas as estruturas da empresa. É uma pessoa prática e ligada diretamente no resultado do SEU trabalho ou no trabalho de seus companheiros diretos ou sua equipe direta.

Antes de mais nada, e antes de ser descrente, o “ateu” acredita que não acredita em nada, e isso é muito significativo. Isso não significa que os “ateus” são pessoas fechadas a novidades ou inovações na sua forma de trabalho ou mesmo a instrumentos corporativos, o que acontece é que em geral eles eles gastam muita da sua energia para combater ou resistir ao que eles acham pouco produtivo ou errado. E são pouco flexíveis quanto ao que eles acreditam. Não os leve a mal, se você pensar bem, isso tudo é muito coerente não é mesmo?

Em outras palavras se você não conseguir explicar no papel como a ITIL, o COBIT, a ISOxxxx, as leis de trânsito ou qualquer conjunto de regras seja diretamente proveitoso ao seu trabalho direto(agregando algum valor) você terá resistência certa. Isso é especialmente difícil, pois esse tipo de profissional é extremamente competente e sempre se assegura que faz seu trabalho da melhor forma. Aqui está o grande desafio dos “middle managers” que tem o papel de não permitir que idéias diferentes da organização se disseminem*(e inclusive, consequentemente, que todos pensem uniformemente com as diretivas da empresa).

Em contra-partida, o “Dogmático” acredita que o único caminho para redenção é a aplicação de metodologias e boas práticas. Ele estuda isso, tira suas certificações, procura cases de sucesso, veste a camisa mesmo, até briga com quem fala que não funciona. (Mas uma vez, aqui existe um ponto de coerência. Aceitar que estas coisas como algo não-funcional significa que você jogou tempo e dinheiro no lixo e ninguém quer isso não é?)

O “Dogmático” enxerga valor nas boas práticas e em geral é bem relacionado na estrutura funcional da empresa. (Afinal de contas se ele não for, ele passa de chato para maluco!) Não obstante, em geral consegue algum apoio gerencial para a aplicação das metodologias – afinal de contas são boas práticas do mercado, ora bolas!

Existem alguns “pecados” que alguns “dogmáticos ” realizam com freqüência. O principal deles é deixar de lado o fator cultural da empresa, e tentar aplicar melhores práticas que as vezes não são aplicáveis, necessárias, ou que existe a necessidade de um fator intermediário para ser alcançado antes de sua aplicação plena. Infelizmente isso é bem freqüente e tem sido o motivo de alguns “rollbacks” na implementações de boas práticas nas empresas. O fator humano é um deles. Em algumas empresas públicas ou com o “espírito de empresas públicas”, muitas vezes é difícil mudar hábitos, e isso deve ser respeitado e levado em conta nos planejamentos, ou então, como diz nosso amigo Silvio Luiz, é “fechar o caixão e beijar a víuva” para seu projeto de implementação.

Então qual o melhor perfil? A resposta é muito simples, como tudo na vida os extremos em geral são prejudiciais, dessa forma uma atitude equilibrada e adaptável é a melhor opção.

Como gestor, é importante enxergar o valor das boas práticas e apoiá-las. Ao mesmo tempo, é importante assegurar sua aplicabilidade. Muitas das metodologias são genéricas(alguns devem ser utilizadas como “frameworks”) e precisam ser customizadas para sua realidade. NEM TUDO PRECISA SER APLICADO no primeiro momento e E NEM TUDO É APLICÁVEL. Em alguns lugares um nível intermediário de maturidade é necessário para usufruir os resultados desejados. E certamente em alguns lugares não vale apena sua aplicação (pelo menos plena), em especial quando regras duras e inflexíveis prejudiquem a produtividade de seus funcionários.

Resumindo, proteja a produtividade de seus funcionários mas procure mostrá-los o valor de algumas regras e controles.

Bons Projetos e Sucesso.

Leandro Santoro.

*A atribuição do papel dos “middle managers” é de autoria de Eric Raymond, numa palestra que ele realizou no FISL 6.

 

 

Comunicação em Projetos – arte de ouvir

Postado por Cesar Campos

http://portal.cseg.eng.br/cesarcampos/images/stories/artigos/comunicacao.jpg
Uma das áreas mais importantes em Gerenciamento de Projetos é a Gestão da Comunicação. E pelo fato de ser uma das mais importantes, também é uma das grandes "vilãs" para o sucesso do projeto.
Todos nós sabemos que um projeto é formado por uma equipe de pessoas, sendo assim vem um grande problema: Como lidar com as diferenças de personalidades dessas pessoas? Como motivar essa equipe? Como gerenciar os conflitos, os interesses?
Esses são alguns dos problemas que encontramos quando trabalhamos com pessoas.

Normalmente em projeto de grande porte, existe um plano de comunicação bem elaborado e também pode haver um membro da equipe responsável para gerenciar a comunicação de todo o projeto.
É fato que em projetos menores muitas vezes a comunicação não é exercitada de maneira eficiente e nem um plano de comunicação existe. Por exemplo, na fase de levantamento de requisitos se não tivermos uma boa comunicação com os stakeholders, certamente não conseguiremos absorver e anotar as suas expectativas. Por outro lado se não conseguirmos sanar as dúvidas de um membro da equipe ou até mesmo deixar claro as suas responsabilidades no projeto, ou seja, o que ele deve entregar e como entregar.
Certamente esses dois casos irão ajudar muito para o fracasso do projeto. [Isso é fato!]

Existem algumas dicas e técnicas que podem nos ajudar:

Para Stakeholders:
* Na fase de levantamento de requisitos, crie uma planilha RTM - Requirements Traceability Matrix, onde você irá listar as expectativas do seu stakeholder e a sua influência no projeto;
* Ouça e escute o que ele tem a dizer, não influencie o mesmo para seus objetivos;
* Esclareça as suas dúvidas em relação às necessidades do mesmo;
* Após identificar o interesse do stakeholder temos que procurar trazê-lo para o projeto para ajudar, ou ao menos, para não atrapalhar o projeto;
* Se você é o líder do projeto, após identificar todas as expectativas do stakeholder converse com o Gerente de Projetos da organização para debater tais itens, esclarecendo todas as dúvidas que surgirem;

Para Equipe:
* Tenha o hábito de anotar suas dúvidas, por mais simples ou complexas que elas possam parecer;
* Determine um prazo alvo para suas dúvidas serem esclarecidas, caso esse prazo chegue ao limite, cobre por respostas;
* Caso precise passar algum pacote de trabalho para um membro da equipe, elabore um dicionário da EAP referente ao trabalho. Seja claro para expor os detalhes e aceitação de tal pacote de trabalho;
* Conversas freqüentes e informais com a equipe ajudam;

Não podemos esquecer que alguns membros da sua equipe serão tímidos, por isso não deixe de convidá-lo para uma conversa, nem sempre o fato de ser calado significa que ele não tem nada para dizer.

Os Líderes e os Gerentes de Projetos precisam ser um bom ouvinte, mas aí vem a pergunta:
http://portal.cseg.eng.br/cesarcampos/images/stories/artigos/screenhunter_01%20jul.%2025%2009.38.jpg
Como tornar-se um bom ouvinte?
A habilidade de ouvir bem, como muitas outras coisas na vida, é uma questão de simples treino. Algumas pessoas já aprenderam a ouvir, outras ainda precisam desenvolver essa habilidade. Nunca é tarde, para se desenvolver essa capacidade.

Alguns exercícios:
* Assuma consigo mesmo o compromisso de treinar diariamente por cinco minutos, estipulando a ocasião durante o dia em que pretende praticar;
* Escolha pessoa ou situação que vai proporcionar a oportunidade para o treinamento (subordinado, colega, mulher ou marido, primeira pessoa que entrar em seu gabinete, etc.);
* Procure ficar ouvindo a pessoa em questão durante o prazo já estipulado;
* Evite interromper, acumulando dúvidas eventuais para esclarecer em momento oportuno;
* Observe seu próprio comportamento: como é a experiência de ouvir?
* Você tem muita vontade de interromper ou de completar as frases do outro?
* Você chega a desligar, permitindo que outros assuntos invadam seu espaço?
* Você chega a ficar ansioso, impaciente?
* Repita o exercício diariamente durante três semanas, procure corrigir as disfunções à medida que você as identifica;

A habilidade de ouvir conquista-se por meio do domínio de uma série de pequenas técnicas e atitudes que serão adquiridas com treino e tempo.
Simplesmente a comunicação é fundamental em projetos e o ato de ouvir é uma peça fundamental para um líder ou um gestor. Ouvindo podemos aprender ou perceber algo novo, enquanto o ato de falar nos limita ao processamento de idéias já formadas. Sendo assim vale a pena investir na habilidade de ouvir.
Com uma boa comunicação e com a capacidade de ouvir um membro da equipe, você conseguirá identificar detalhes importantes do projeto para seu sucesso. Além de estar sendo um profissional mais eficaz e, ao mesmo tempo, irá aprimorar sua imagem como pessoa.

Marcadores: comunicação, ouvir, Stakeholders, sucesso do projeto

Como iniciar uma carreira de sucesso em Gerenciamento de Projetos? Esta é uma área em ascensão, como demonstram os inúmeros cursos, especializações, certificações, eventos e publicações na área em anos recentes.

E ninguém melhor para falar sobre sucesso em uma carreira do que uma pessoa que chegou lá. É o caso do Ricardo Vargas, autor conhecido no âmbito do Gerenciamento de Projetos no Brasil, e que é “Especialista em planejamento, gestão e controle de projetos. Foi, nos últimos dez anos, responsável por mais de 30 projetos de grande porte no Brasil, coordenando uma equipe de mais de 500 profissionais de gerenciamento de projetos nas áreas de telecomunicações, informática, finanças e energia, com um portfólio de investimentos superior a 5 bilhões de dólares.”

Em mais um de seus podcasts sobre gerenciamento de projetos (tema constante de artigos aqui do Efetividade), desta vez Vargas escolheu um tema que me interessou bastante: conselhos dedicados a quem está começando sua carreira na área, frisando que se trata de um apanhado de opiniões, e não de um tratado sobre o que é certo ou errado na carreira de cada um.

Ele começa elencando o que considera como os fatores clássicos de sucesso em gerenciamento de projetos: entender o que é projeto e o que está acontecendo na área de projetos, e especialmente entender que projeto está relacionado a investimento, a novos negócios, a desafios, a trabalhos não-rotineiros.

Para Vargas, os pilares de uma carreira sólida na área são três: desenvolvimento profissional com experiência internacional (mesmo que seja participação em congressos e cursos) + certificação; relacionamento e networking; e a experiência, mesmo que começando por baixo – ele frisa que às vezes vale a pena até mesmo aceitar determinados projetos sem lucro financeiro para si, para adquirir a experiência e até para enriquecer o currículo.

Se ele tivesse que reiniciar sua carreira na área hoje, eis o que ele priorizaria:

  • Treinamento formal – MBA, especialização ou outra pós-graduação em gerenciamento de projetos, curso específico, curso de férias fora do país, ou o que estiver ao alcance. Pensar globalmente, mesmo que só possa agir localmente. Vale muito para o currículo, e agrega à experiência.
  • Certificação: Ele começaria por obter a qualificação necessária para poder buscar a certificação PMP, do PMI, que é o que o mercado conhece e pede. Deixaria outras certificações que servem como diferencial (PRINCE2 e outras) para um segundo momento, como foi de fato o caso da carreira dele.
  • Networking profissional: investiria muito no networking profissional, com um profile caprichado no LinkedIn (existe algum equivalente nacional tão bem aceito?), participando ativamente nos fóruns e listas de discussão, indo a congressos sem esquecer de trocar cartões e apertar mãos.
  • Idiomas: para ele, é fundamental aprender e dominar outro idioma, preferencialmente o inglês, que é básico. Outros idiomas são diferenciais.

Ele deu ainda uma dica: procurar entrar como voluntário em organizações voltadas ao gerenciamento de projetos, como o PMI, porque é uma grande oportunidade de agregar conhecimento, experiência e enriquecer o networking.

Ele termina lembrando que conselho se fosse bom seria vendido, e não dado, mas estes são os conselhos que ele pode compartilhar conosco. Eu gostei, e recomendo!

Para saber mais, consulte a a área de podcasts do site do Ricardo Vargas, ou ouça diretamente a minha cópia (autorizada) em MP3.

E o Ricardo vargas pode ajudar o seu início de carreira ;-)

Para aqueles que querem ir se adiantando, e não fazem questão de sempre contar com a ortodoxia das literaturas disponibilizadas pelo próprio PMI, sugiro 2 livros que eu li e venho recomendando a colegas que estão ingressando em ambientes orientados a projetos, ambos de autoria do mesmo Ricardo Vargas que nos forneceu o tema do artigo que você está lendo.

 

Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos, 6a. edição: é um “livrão”, em formato típico de material escolar (bastante apropriado) que em suas 276 páginas apresenta um panorama geral (e bem prático) do gerenciamento de projetos. Vai desde os conceitos até a aplicação, bom como primeiro livro ou material introdutório. autoria do mesmo Ricardo Vargas que nos forneceu o tema do artigo que você está lendo.

 

 

 

 

 

 

Manual Prático do Plano de Projeto, 3a. edição: também em formato grande, traz em suas 232 páginas os modelos de documentos de projetos, desde o termo de abertura (”project charter”) até o término dos processos previstos no PMBOK. Além de trazer os modelos, ele traz ainda exemplos de preenchimento para um projeto fictício, e inclui um CD-ROM com os arquivos correspondentes. Não é um bom primeiro livro, porque as explicações e conceitos são bem mais superficiais, mas pode ajudar bastante na prática dos projetos.

Procure ambos na biblioteca ou na sua livraria preferida, folheie e verifique se vale a pena comprar. Eu comprei o primeiro, e estou considerando seriamente comprar também o meu próprio exemplar do segundo. autoria do mesmo Ricardo Vargas que nos forneceu o tema do artigo que você está lendo.

 

 

Leia também

 

Gerenciamento de Projetos:

O gerenciamento de projetos é um assunto que está em voga, e artigos sobre o tema pipocam em todas as mídias. A Computer World não foge à regra, e publicou na sua seção Management um interessante artigo propondo os 10 mandamentos do gerenciamento de projetos.

Segundo o subtítulo, estes mandamentos vão levar sua organização à terra prometida da cultura baseada em projetos. Eu não faria uma afirmação tão ampla, mas tenho certeza de que eles podem provocar algumas reflexões interessantes.

Por ser produto da Computer World e ter como autor James M. Kerr, cuja carreira foi na gestão de TI, o texto tem forte inclinação para os aspectos que afetam a área de tecnologia nas organizações. Mas mesmo que não seja o seu caso, certamente você pode adaptar grande parte das propostas à sua realidade.

Aparentemente, o artigo “The Ten Commandments of Project Management” ainda não foi traduzido pela Computer World brasileira. Mas abaixo você encontra uma tradução parcial, com algumas adaptações e flexões para melhor adaptar o texto à realidade brasileira.

Leia também: “Gerenciamento de Projetos: uma versão “light” para aplicar em pequenos projetos” e “Gerenciamento de projetos pessoais: Não faça suas estimativas no vácuo“, aqui no Efetividade.net.

 

Os 10 mandamentos do gerenciamento de projetos

 

I – Estreitarás teus escopos. Nada é pior do que um projeto interminável. Ele pode sugar todos os recursos e esgotar até mesmo a equipe mais motivada. Para manter os projetos firmes e orientados, concentre seus maiores esforços em projetos menores, que tenham entregas (”deliverables“) alcançáveis e que possam cumprir seus prazos. A longo prazo, uma série de vitórias pequenas tem mais impacto sobre a organização do que uma gigantesca orquestra sinfônica que nunca chega a tocar.

II – Não tolerarás equipes inchadas. Uma boa maneira de começar com o pé direito é garantir que a equipe do projeto terá o tamanho certo. Equipes maiores são mais difíceis de motivar e administrar, e as personalidades podem ficar no meio do caminho, atrapalhando o trabalho. Não existe um tamanho ideal para a equipe, mas uma boa regra empírica é ter uma pessoa para cada papel e um papel para cada pessoa. Se alguns integrantes tiverem que desempenhar mais de um papel, tudo bem – se você for errar o dimensionamento, erre a favor de uma equipe menor.

III – Exigirás dedicação de todas as áreas envolvidas. Se a área de TI aceitar um prazo apertado, mas parte dos documentos de projeto precisar ser aprovado pelas demais áreas da organização, e elas não estiverem comprometidas da mesma forma, o projeto acaba virando uma gincana. Se as áreas de negócio aceitam um prazo apertado, mas dependem de um aplicativo a ser desenvolvido pela área de TI, que não está comprometida da mesma forma, o projeto também acaba virando uma gincana. O gerente de projeto deve se posicionar de forma a que todas as áreas diretamente envolvidas no sucesso do projeto estejam comprometidas, e disponíveis na medida da necessidade, desde o princípio.

IV – Estabelecerás um comitê para analisar o andamento. O comitê de acompanhamento, qualquer que seja seu título oficial, é o corpo diretivo do projeto. Ao mesmo tempo em que lida com questões relacionadas às políticas e estratégias da empresa, ele pode e deve remover as lombadas e obstáculos do caminho do projeto. Um arranjo típico envolve reuniões quinzenais das áreas de gerência intermediária envolvidas no projeto, para analisar seu andamento e verificar como se envolver das formas descritas acima.

V – Não consumirás tua equipe. O ‘burnout’, ou esgotamento físico e mental dos membros da equipe, causado pelo stress e esforço das atividades, não é incomum. Fique atento às necessidades das pessoas e evite este efeito que reduz a efetividade da equipe – não planeje de forma que o envolvimento das pessoas vá exigir sacrifícios incomuns e continuados. Em particular, evite o efeito do envolvimento serial: o popular efeito “sempre os mesmos” – pessoas que se destacam por resolver bem os problemas que recebem, e assim acabam sendo envolvidos em mais projetos do que seria racional, gerando stress para elas, e disputa de recursos para os projetos.

VI – Buscarás apoio externo quando necessário. Adotar consultores em gerenciamento de projetos é uma forma de prevenir o esgotamento. Além de aumentar as equipes, os especialistas externos muitas vezes podem trazer valiosas novas idéias, perspectivas e energias. É essencial trazer o profissional certo no momento certo: especialistas nos aspectos técnicos e de mercado não são a mesma coisa que especialistas em gerenciamento de projetos. Considere as características do projeto e da equipe antes de definir o tipo de apoio externo necessário.

VII – Darás poder às tuas equipes. Equipes de projeto que já estejam se esforçando para cumprir seus escopos e prazos não precisam ter preocupações adicionais com questões formais como o preenchimento de formulários de registro de atividades para seus departamentos, ou participação em reuniões periódicas de seu órgão de origem. Ao invés disso, eles devem ter o poder discricionário de dedicar-se às atividades essenciais e que agregam valor ao projeto, e a estrutura deve se esforçar para adaptar-se a estas condições. Mas é importante que os membros da equipe correspondam a esta confiança, saibam claramente o que se espera deles e de que forma devem usar sua iniciativa.

VIII – Usarás ferramentas de gerenciamento de projetos. Tarefas mundanas de gerenciamento de projetos podem ser automatizadas. Procure ferramentas que ofereçam acompanhamento do andamento, gerenciamento de tarefas, gerenciamento do fluxo de trabalho e análise de recursos, e que funcionam em uma plataforma de Intranet que promova o compartilhamento e a comunicação. Mas lembre-se de que usar tecnologias que acrescentem uma camada extra de complexidade a um projeto já desafiador por si pode não ser uma boa idéia.

IX – Reconhecerás o sucesso. Todos os participantes do projeto devem ser reconhecidos de forma positiva pelo esforço que praticaram. As recompensas não precisam ser extravagantes. É fundamental que a origem real do reconhecimento – seja a Presidência, a direção da filial regional, o principal patrocinador do projeto ou o seu gerente – fique clara para todos, e que se manifeste de forma tão individual e personalizada quanto possível.

X – Não tolerarás gambiarras. Políticas sólidas de gerenciamento de projetos devem eliminar antecipadamente a tentação de recorrer a alternativas rápidas e rasteiras, que só levam a erros, desperdício, retrabalho e frustração.

Estes são os mandamentos da gestão de projetos segundo James Kerr. Que tal aproveitar para incluir nos comentários alguns mandamentos adicionais que você aprendeu em sua própria experiência ou que sejam adotados em sua organização?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

HISTORIA DO GERENCIAMENTO DE PROJETOS:

Gerência de projetos

 

Gerência de projetos, gestão de projetos, gerenciamento de projetos ou ainda administração de projetos é a aplicação de conhecimentos, habilidades e técnicas na elaboração de atividades relacionadas para atingir um conjunto de objetivos pré-definidos. O conhecimento e as práticas da gerência de projetos são mais bem descritos em termos de seus processos componentes.

Reduzida à sua forma mais simples, a gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto necessário durante o ciclo de vida do projeto. O risco de fracasso aumenta de acordo com a presença de incerteza durante todos os estágios do projeto.

Um ponto-de-vista alternativo diz que gerenciamento de projetos é a disciplina de definir e alcançar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço, etc).

A gerência de projetos é frequentemente a responsabilidade de um indivíduo intitulado gerente de projeto. Idealmente, esse indivíduo raramente participa diretamente nas atividades que produzem o resultado final. Ao invés disso, o gerente de projeto trabalha para manter o progresso e a interação mútua progressiva dos diversos participantes do empreendimento, de modo a reduzir o risco de fracasso do projeto, podendo arcar com qualquer ônus.

 

História da Gerência de Projeto

 

Como uma disciplina, a gerência de projeto foi desenvolvida de diversos campos de aplicação diferentes, incluindo a construção, a engenharia mecânica, projetos militares, etc. Nos Estados Unidos, o "pai" da gerência de projeto é Henry Gantt, chamado o pai de técnicas do planejamento e do controle, que é conhecido pelo uso do gráfico de barras como uma ferramenta de gerência do projeto, para ser um associado as teorias de Frederick Winslow Taylor da administração científica, e para seu estudo do trabalho e da gerência do edifício do navio da marinha. Seu trabalho é o precursor a muitas ferramentas de gerência modernas do projeto, tais como a WBS (Work Breakdown Structure) ou EAP (Estrutura Analítica do Projeto) de recurso que avalia o trabalho.

Os anos 50 marcam o começo da era moderna da gerência de projeto. Outra vez, nos Estados Unidos, antes dos anos 50, os projetos foram controlados basicamente se utilizando os gráficos de Gantt, técnicas informais e ferramentas. Nesse tempo, dois modelos programando do projeto matemático foram desenvolvidos:

  1. Program Evaluation and Review Technique ou o PERT, desenvolvido como a parte programa do míssil do submarino Polaris da marinha dos Estados Unidos' (conjuntamente com o Lockheed Corporation); e
  2. Critical Path Method (CPM) desenvolvido em conjunto por DuPont Corporation e Remington Rand Corporation para projetos da manutenção de planta. Estas técnicas matemáticas espalharam-se rapidamente em muitas empresas.

Em 1969, o Project Management Institute (PMI) foi dando forma para servir ao interesse da indústria da gerência de projeto. A premissa de PMI é que as ferramentas e as técnicas da gerência de projeto são terra comum mesmo entre a aplicação difundida dos projetos da indústria do software à indústria de construção. Em 1981, os diretores do PMI autorizaram o desenvolvimento de o que se transformou em um guia de projetos o Project Management Body of Knowledge, contendo os padrões e as linhas mestras das práticas que são usados extensamente durante toda a profissão.

 

 O gerente de projeto

 

Um projeto é desenvolvido pelo profissional denominado "gerente de projeto". Este profissional raramente participa das atividades diretas do projeto que produzem os resultados. Sua função é "gerenciar" o progresso do empreendimento e através das variáveis (qualidade, custo, prazo e escopo) verificar seus desvios. Desta forma, seu objetivo geral é proporcionar que as falhas inerentes aos processos sejam minimizadas.

Um gerente de projeto tem que determinar e executar as necessidades do cliente, baseado nos seus próprios conhecimentos. A habilidade de adaptar-se aos diversos procedimentos pode lhe proporcionar um melhor gerenciamento das variáveis e desta forma uma maior satisfação do cliente.

Em campo, um gerente de projeto bem sucedido deve poder imaginar o projeto inteiro do seu começo ao seu término e desta forma assegurar que esta visão seja realizada.

Qualquer tipo de produto ou serviço—edifícios, veículos, eletrônica, software de computador, serviços financeiros, etc. -- pode ter sua execução supervisionada por um gerente de projeto e suas operações por um gerente de produto.

 

Artigo principal: Gerente de projeto

Um gerente de projetos é um profissional no campo de gerência de projetos que tem a responsabilidade de planejar e controlar a execução de projetos em diversas áreas de atuação, como a construção civil, arquitetura e desenvolvimento de software, entre outras áreas. É o profissional responsável pela condução do projeto e deve contar com o respaldo de patrocinadores (sponsors, segundo a nomenclatura PMI), normalmente indivíduos que estejam fora do projeto a ser executado.

O gerente e sua equipe deprojetos planejam e coordenam o desenvolvimento do projeto colhendo métricas, suprindo necessidades, recrutando recursos adequados e mantendo o foco na meta de projeto, além de:

Referências gerais

  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Third Edition.ed.  |

 

Abordagens

Na indústria de informática, geralmente há dois tipos de abordagens comumente utilizadas no gerenciamento de projetos. As abordagens do tipo "tradicional" identificam uma sequência de passos a serem completados. Essas abordagens contrastam com a abordagem conhecida como desenvolvimento ágil de software, em que o projeto é visto como um conjunto de pequenas tarefas, ao invés de um processo completo. O objetivo desta abordagem é reduzir ao mínimo possível o overhead. Essa abordagem é bastante controversa, especialmente em projetos muito complexos. Mesmo assim, tem conquistado adeptos em números crescentes.

Nas últimas décadas, emergiram uma série de abordagens na indústria em geral. Dentre essas abordagens se destaca a abordagem do PMBOK, que tem se tornado um padrão de facto em diversas indústrias.

 Abordagem tradicional

Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto:

  1. Iniciação;
  2. Planejamento;
  3. Execução;
  4. Monitoramento e Controle; e,
  5. Encerramento.

Nem todos os projetos vão seguir todos estes estágios, já que projetos podem ser encerrados antes de sua conclusão. Alguns projetos passarão pelos estágios 2, 3 e 4 múltiplas vezes.

O projeto ou empreendimento visa a satisfação de uma necessidade ou oportunidade, definida no texto acima como fase inicial na qual existem muitas áreas e/ou pessoas envolvidas.

Em geral sempre existe mais que uma solução ou alternativas para atender às mesmas necessidades. A técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas.

A primeira, de baixo custo, que atende as necessidades mínimas para ser funcional. A segunda tenta atender a maior parte das as exigências das diversas áreas envolvidas no escopo, que resulta num projeto com custo muito maior e pouco competitivo.

A partir de ambas as alternativas é desenvolvida uma solução intermediária entre as mesmas, que atende a uma boa parte das exigências com um custo competitivo.

Vários setores utilizam variações destes estágios. Por exemplo, na construção civil, os projetos tipicamente progridem de estágios como Pré-planejamento para Design Conceitual, Design esquemático, Design de desenvolvimento, construção de desenhos (ou documentos de contrato), e administração de construção. Embora os nomes difiram de indústria para indústria, os estágios reais tipicamente seguem os passos comuns à resolução de problemas (problem solving): definir o problema, balancear opções, escolher um caminho, implementação e avaliação.

Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas, dentre as quais se destacam:

 

 

 

 

As Variáveis

 

Alguns empreendimentos necessitam ser executados e entregues sob determinadas variáveis. As variáveis principais também podem ser denominadas como tradicionais. O gerenciamento de projetos tenta adquirir controle sobre três variáveis:

  • tempo;
  • custo; e,
  • escopo.

Isto é conhecido também como "triângulo da gerência de projeto", onde cada lado representa uma variável. Um lado do triângulo não pode ser mudado sem impactar no outro. Como comentado anteriormente, alguns profissionais entendem que a variável ´qualidade’ está separada do escopo e o definem como sendo uma quarta variável.

A restrição do tempo influencia o prazo até o termino do projeto. A restrição de custo informa o valor monetário incluído no orçamento disponível para o projeto. Já a restrição do escopo designa o que deve ser feito para produzir o resultado de fim do projeto. Estas três variáveis estão freqüentemente competindo: o escopo aumentado significa tipicamente o tempo aumentado e o custo aumentado, uma restrição apertada de tempo poderia significar custos aumentados e o escopo reduzido, e um orçamento apertado poderia significar o tempo aumentado e o escopo reduzido.

A disciplina da gerência de projeto é sobre fornecer as ferramentas e as técnicas que permitem a equipe de projeto (não apenas ao gerente de projeto) organizar seu trabalho para se encontrar com estas variáveis.

 Tempo

O tempo requerido para terminar os componentes do projeto, é normalmente influenciado quando se pretende baixar o tempo para execução de cada tarefa que contribui diretamente à conclusão de cada componente. Ao executar tarefas usando a gerência de projeto, é importante cortar o trabalho em diversas partes menores de modo que seja fácil definirmos condições de criticidade e de folgas.

 Custo

O Custo para desenvolver um projeto depende de diversas condições iniciais que possuímos para o desenvolvimento de cada projeto tais como: taxas labor, taxas materiais, gerência de risco, planta (edifícios, máquinas, etc.), equipamento, e lucro.

 Escopo

São as exigências especificadas para o resultado fim, ou seja, o que se pretende, e o que não se pretende realizar. A qualidade do produto final pode ser tratada como um componente do escopo. Normalmente a quantidade de tempo empregada em cada tarefa é determinante para a qualidade total do projeto.

Algumas literaturas definem como quatro variáveis, sendo qualidade a quarta variável. Contudo a qualidade é um dos principais componentes do escopo.

Estas variáveis podem ser dadas por clientes externos ou internos. O(s) valor(es) das variáveis remanescentes está/estão a cargo do gerente do projeto, idealmente baseado em sólidas técnicas de estimativa. Os resultados finais devem ser acordados em um processo de negociação entre a gerência do projeto e o cliente. Geralmente, os valores em termos de tempo, custo, qualidade e escopo são definidos por contrato.

 

Padrões de gerência de projetos

 

Ao longo do tempo, houve diversas tentativas para desenvolver padrões internacionais de gerência de projetos. Dentre elas, destacam-se:

[editar] Ver também

[editar] Referências gerais

  • Heizer, Jay; Render Barry. "Operations Management": International Edition, 7ª Edição 2004, ISBN 131209744
  • Gaither, Norman. Production and Operations Management" International Edition, 5ª Edição 1992, ISBN 30746221
  • Monks, Joseph G. " Administração da Produção" Editora McGraw Hill, 1ª Edição 1987, ISBN 74502778

[editar] Ligações externas

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Frederick Winslow Taylor (Filadélfia, Pensilvânia, 20 de Março de 1856 - Filadélfia, Pensilvânia, 21 de Março de 1915) mais conhecido por F. W. Taylor, foi um engenheiro mecânico estadunidense, inicialmente técnico em mecânica e operário, formou-se engenheiro mecânico estudando à noite. É considerado o "Pai da Administração Científica" por propor a utilização de métodos científicos cartesianos na administração de empresas. Seu foco era a eficiência e eficácia operacional na administração industrial.

Sua orientação cartesiana extrema é ao mesmo tempo sua força e fraqueza. Seu controle inflexível, mecanicista, elevou enormemente o desempenho das indústrias em que atuou, todavia, igualmente gerou demissões, insatisfação e estresse para seus subordinados e sindicalistas.

Elaborou os primeiros estudos essenciais:

  • Em relação ao desenvolvimento de pessoal e seus resultados, acreditava que oferecendo instruções sistemáticas e adequadas aos trabalhadores, ou seja, treinando-os, haveria possibilidade de fazê-los produzir mais e com melhor qualidade.
  • Em relação ao planejamento a atuação dos processos, achava que todo e qualquer trabalho necessita, preliminarmente, de um estudo para que seja determinada uma metodologia própria visando sempre o seu máximo desenvolvimento.
  • Em relação à produtividade e à participação dos recursos humanos, estabelecida a co-participação entre o capital e o trabalho, cujo resultado refletirá em menores custos, salários mais elevados e, principalmente, em aumentos de níveis de produtividade.
  • Em relação ao autocontrole das atividades desenvolvidas e às normas procedimentais, introduziu o controle com o objetivo de que o trabalho seja executado de acordo com uma seqüência e um tempo pré-programados, de modo a não haver desperdício operacional.
  • Inseriu, também, a supervisão funcional, estabelecendo que todas as fases de um trabalho devem ser acompanhadas de modo a verificar se as operações estão sendo desenvolvidas em conformidades com as instruções programadas. Finalmente, apontou que estas instruções programadas devem, sistematicamente, ser transmitidas a todos os empregados.