Gestão de Projetos by Alexandre

Governança Corporativa e Projetos Estratégicos

alexandrecreis — Wed, 06 Jul 2011 11:06:48 +0000

Escrito por Paul C Dinsmore e Pedro C Ribeiro Por PAUL C. DINSMORE e PEDRO C. RIBEIRO

Published in PM World Today – April 2007 (Vol. IX, Issue IV), a free monthly eJournal.

PM Word Today

A experiência indica que estratégias brilhantemente concebidas, mas não implementadas eficazmente, podem resultar em perdas para os acionistas. Assegurar a concepção e a execução de estratégias é talvez o mais importante fator para o sucesso organizacional.

Alcançar um crescimento sustentável e rentável através de uma execução precisa de estratégias é a melhor forma de assegurar a criação de valor para os acionistas, e uma das tarefas primordiais dos CEOs (Chief Executive Officer/Diretor Presidente). Sem uma abordagem estruturada para a execução, alvos estratégicos poderão não ser atingidos. A execução é crítica para o sucesso de uma organização e exige um processo disciplinado para fazer as estratégias acontecerem. Pesquisas indicam que as organizações de alto desempenho utilizam melhores práticas que relacionam estratégia à execução de seus projetos.

A prosperidade organizacional se baseia em uma combinação de projetos certos, executados da forma correta. A prosperidade dependerá não somente de uma boa estratégia, mas de se implementar esta estratégia de uma forma eficaz. O sucesso empresarial irá depender da gestão efetiva de uma miríade única de iniciativas temporais e finitas, chamadas projetos, através de toda a organização.

Enquanto uma boa gestão de projetos não pode salvar uma empresa de uma estratégia mal concebida, uma gestão de projetos ineficiente pode prejudicar uma boa estratégia. Pesquisas do Standish Group publicadas no terceiro trimestre de 2004, sobre o setor de TI indicavam que 18% dos projetos investigados tinham falhado (i.e., tinham sido cancelados antes do término, ou finalizados, mas nunca utilizados) e 53% estariam prejudicados (i.e. atrasados, acima do orçamento e/ou com menos dos que as funções e funcionalidades requeridas).

Projetos-problema representam más notícias para acionistas e CEOs de empresas. A má gestão de projetos pode trazer impactos na satisfação e percepção de clientes, no relacionamento com clientes e em potenciais vendas futuras. Projetos acima do custo impactam margens de lucro e aumentam a necessidade de capital de giro. Atraso na obtenção de aceite do cliente aumenta o contas a receber e a necessidade de financiamento, com impacto negativo no fluxo de caixa da empresa. O lançamento de novos produtos com atraso representa perda de fluxo de caixa de novas vendas. Problemas com cronogramas de implantação de soluções voltadas ao aumento da eficiência corporativa, tais como o ERP, frustram as expectativas de obtenção dos benefícios esperados de redução de custos, assim como multas contratuais e litígios, devido a falhas de execução, podem fazer naufragar margens de lucros e carreiras.

Focando na Governança da Gestão de Projeto

Uma vez que a implementação efetiva de uma combinação certa de projetos certos é imperativo para as organizações sobreviverem e prosperarem, é fundamental que os CEOs se assegurem que uma governança adequada esteja definida para o gerenciamento de projetos através de toda a organização. No seu nível mais elevado, a governança envolve um conjunto de relacionamentos entre a diretoria, acionistas, e outros grupos de interessados. Através de mecanismos de governança, uma organização determina não somente seus objetivos estratégicos e operacionais, mas também cria as condições para assegurar que processos, procedimentos, práticas, e estruturas organizacionais adequadas estejam implantadas para alcançar os objetivos estabelecidos e controlar o seu atingimento. A governança de gestão de projetos define estes relacionamentos e políticas aplicadas à gestão de múltiplos projetos em uma organização. A governança de gestão de projetos estabelece os processos e procedimentos necessários para assegurar a gestão adequada de projetos estratégicos.

Conclusões

Os CEOs estão sendo constantemente desafiados a transformar estratégias em resultados. No entanto, resultados dependem de uma efetiva implementação dos projetos certos. Os CEOs precisam se assegurar que sob a governança corporativa, esteja contemplada uma política de governança para a gestão efetiva dos projetos estratégicos.

Paul C. Dinsmore, PMP, PMI Fellow, é autor de 11 livros sobre temas gerenciais e projetos incluindo Winning in Business with Enterprise Project Management (Amacom, NY, 1998) e The AMA Handbook of Project Management, Second Edition (2005, Amacom, NY). Paul Dinsmore é Presidente da Dinsmore Associates, empresa de consultoria e treinamento operando globalmente, com escritórios no Rio de Janeiro, Brasil. dinsmore@dinsmore.com.br

Pedro C. Ribeiro, MBA, PMP é consultor em gestão de projetos com mais de 25 anos de experiência executiva e de consultoria. Tendo sido diretor da Ernst & Young Consulting, Unisys, EDS é immediate past Regional Chair, Central & South America do PMI IT&Telecom SIG, e membro do Operational Oversight Committee da PMI Educational Foundation. Pedro Ribeiro é baseado em São Paulo, Brasil. pedro.c.ribeiro@terra.com.br

Os 7 Passos da Gestão de Projetos

alexandrecreis — Sun, 17 Oct 2010 20:52:37 +0000

Os 7 Passos da Gestão de Projetos

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 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:

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, “checkpoints”, 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

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, clientes 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”.

Fonte:

Fernando C Barbi, PMP

http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/GerencProjetos.mspx

Exemplo de uma implantação do Service Desk em uma Empresa

alexandrecreis — Wed, 29 Sep 2010 21:30:18 +0000

Este é um exemplo didático no caso citado é do processo de implantação do Service Desk na Empresa CASSI – Caixa de Assistência dos Funcionários do Banco do Brasil.

A Empresa – (Patrocinador)

A Caixa de Assistência dos Funcionários do Banco do Brasil (CASSI) é uma empresa de autogestão em saúde fundada em 27 de janeiro de 1944 por um grupo de funcionários do BB. O objetivo era ressarcir as despesas de saúde dessa população. Com 66 anos de existência, a CASSI é hoje uma das maiores instituições sem fins lucrativos administradoras de planos de saúde do País. Atualmente tem mais de 817 mil participantes.

Problematização

A Empresa trabalha com diversas ferramentas, aplicativos e softwares, em suas 27 unidades operacionais. Com isso, surgem diversos problemas, erros, dúvidas, necessidades e até esclarecimentos, sendo assim, foi elaborado um projeto para atender esses clientes internos criando um único ponto de contato entre os provedores de serviços e os usuários no dia a dia.

Proposta

Service Desk

É o único ponto de contato (SPOC) entre os provedores de serviços e os usuários no dia a dia. Como ponto focal para reportar incidentes e abrir chamados de serviços, é responsabilidade do Service Desk manter os usuários informados sobre os eventos de serviços, ações e resoluções de suas questões. O Service Desk está na linha direta do impacto do SLA, por isto necessita de rapidez no fluxo de informação.

Gerência de Incidentes

É responsável pela restauração da operação de um serviço com o menor tempo possível, a fim de minimizar os aspectos negativos sobre a operação dos negócios, garantindo os melhores níveis de qualidade e disponibilidade para os usuários.

Gerência de Problemas

Para a gerência de problemas é necessário a integração de alguns processos, principalmente o de Incidentes, que garantirá a correta informação a fim de identificar efetivamente e eficientemente a causa do incidente e tendências. Também é necessário que a gerência de problemas esteja próxima ao processo de gerência de disponibilidade para identificar estas tendências e remediar ações. Isto se dá através da investigação, diagnóstico e solução de problemas.

Gerência de Disponibilidade

É responsável pelo desenho, implementação, medição e gerência dos serviços de TI, garantindo que a disponibilidade do negócio seja consistentemente alcançada. A gerência de disponibilidade requer um conhecimento profundo das razões de porque o serviço de TI falhou e o tempo que se levará para que volte a normalidade. O gerenciamento de incidentes e de problemas está muito integrado, provendo informações que asseguram ações corretivas apropriadas.

Gerência de Mudanças

Garante que seja dada a todas as partes afetadas por uma mudança a oportunidade de acompanhar e entender os impactos da mudança. As gerências de configuração, mudança e implantação são pontos chaves para prover e agregar valor as informações necessárias a uma mudança. Os usuários precisam saber exatamente qual o processo para a requisição de uma mudança e seus impactos.

Gerência de Configuração

Assegura que apenas componentes autorizados (itens de configuração – software, hardware, documentos, processos, procedimentos e outros ) são usados no ambiente de TI, e que todas as mudanças nestes componentes serão gravadas e rastreadas durante todo o ciclo de vida do componente.

Gerência de Implantação

Coordena e gerencia implantação de novos produtos ou atualizações tecnológicas no ambiente operacional. Através do seu planejamento, validação e instalação, implementa de forma controlada e sistemática a nova tecnologia.

Gerência do Nível de Serviço

Permite entregar exatamente o que foi acordado, garantindo que a qualidade dos serviços prestados atendem às reais necessidades do negócio. Com este novo conceito integraremos as equipes de atendimento ao usuário e suporte a hardware, com profissionais que apresentem um perfil mais amplo, podendo assumir responsabilidades de forma mais flexível atendendo ao dinamismo do negócio.

Linha do Tempo do Projeto

Linha do Tempo

Modelagem

Modelagem
Termos de Referência	Identificação	Descrição	Inserção	Aprovisionamento e Controle	Apresentação (Fases da Modelagem)
Verificar o local aonde será alocado o Service Desk; Levantamento dos Requisitos; Estudo das Oportunidades	Como atender e resolver todas as solicitações, problemas, dúvidas e esclarecimentos que o cliente deseja	Local aonde será alocada a central de Service Desk	Verificar o ambiente se vai ser Windows ou Linux; Aplicativos gratuitos, pagos ou desenvolvidos (customizado)	Qual a forma de contratação? (Terceirizado, CLT, PJ, etc.)	Estrutura (Máquinas, Funcionários – Salários, Softwares, Ambiente Físico, Contas (Água, Luz, Telefone), Hardware)
Criar Manuais de Procedimentos	Propor um conjunto com vários softwares para assim, ter uma integração da solução	Construir uma forma de readequar os problemas similares para resolução rápida e eficaz	Empregar o máximo de pessoas qualificadas da região;	Estudo de valores na empresa (financeiros – bens tangíveis e não-financeiros bens intangíveis)	Levantamento de tudo o que pode interferir no projeto (Investimento insuficiente, stakeholders desistirem, mudanças de escopo, etc.)
Criar Manuais de Procedimentos	Levantamento de quantos usuários, quantos softwares, quantos aplicativos, quantos funcionários serão necessários, etc.	Local com pouco barulho, boa entrada de luz, ambiente espaçoso	Empregar pessoas com deficiência, mas que sejam aptas para as atividades de Service Desk	Solução (de rede, intranet, Internet, acessos, nível de conhecimento dos funcionários, ambiente físico)	Finalização nas atividades de Estudo de Viabilidades e começar o Projeto
Regras de Negócio		Procedimento do fluxo de atendimento (desde a abertura até a finalização do chamado)	Protótipo, visualização e entendimento (interface)	Realizar um estudo de como será implantado a visão sistêmica (visão por processos)
Regras de Negócio	Acordo e Níveis de SLA.		Revisão e correção das etapas anteriores

Definição do modelo de qualidade

No Projeto de Implementação de Service Desk será escolhido o modelo de qualidade e o Modelo de Gestão ITIL. O MPS.BR ou Melhoria de Processos do Software Brasileiro é simultaneamente um movimento para a melhoria da qualidade (Programa MPS.BR) e um modelo de qualidade de processo (Modelo MPS) voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil.

Ele é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro, bem como é compatível com o CMMI.

No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação as normas estrangeiras, sendo ideal para micro, pequenas e médias empresas.

Práticas serão utilizadas

MA-MPS – Método de avaliação para melhoria do processo de software e Modelo de Gestão ITIL.

Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresa e organizações que implementaram o MR-MPS. Avaliação MA-MPS:

Equipe de avaliação e auditoria: 3 a 8 pessoas, sendo:

1 Auditor Líder

no mínimo 1 Auditor adjunto

no mínimo 1 Especialista da empresa

Duração: 2 a 4 dias;

Validade: 2 anos;

***Obs: Dessa avaliação que o restante dos prazos serão definidos.

Estruturação da Avaliação/Auditoria:

Planejar e preparar auditoria

Plano de Avaliação / Descrição dos indicadores de processo;

Conduzir Auditoria

Resultado da Auditoria;

Relatar resultados

Relatório da avaliação;

Registrar e publicar resultados

Controles

Análise dos Processos:

1.1 – O processo é executado;

2.1 – O processo é gerenciado;

2.2 – Os produtos de trabalho do processo são gerenciados;

3.1 – O processo é definido;

3.2 – O processo está implementado;

4.1 – O processo é medido;

4.2 – O processo é controlado;

5.1 – O processo é objeto de inovações;

5.2 – O processo é otimizado continuamente;

5.3 – Revisão dos Manuais e Procedimentos.

Perfis profissionais

Serão necessários atendentes 1º nível (operadores), atendentes 2º nível (atendentes com mais experiência), analistas (pessoas com maior conhecimento e experiência no ramo), supervisor (efetuar o monitoramento, controle e transparência) e Coordenador (Manter equipe e equipamentos funcionando).

Competências, habilidades e atividades

Atendente de 1º Nível: atender, esclarecer e efetuar o primeiro atendimento aos problemas relatados pelos usuários, se necessário repassar o chamado para o próximo nível.

Atendente de 2º Nível: efetuar o segundo atendimento aos problemas relatados pelos usuários, se necessário repassar o chamado para o próximo nível.

Analistas: analisar e resolver o problema, propor melhorias, ferramentas, aplicativos e soluções para evitar que ocorra.

Supervisor: gerenciar os atendentes, níveis de SLA, administrar e monitorar as ligações.

Coordenador: Coordenar toda equipe, relatórios gerenciais, etc.

Perfil (Cargos e Salários):

Atendente de 1º Nível: 01 salário mínimo e meio, + CLT.

Atendente de 2º Nível: 03 salários mínimos + CLT

Analistas: 10 salários mínimos + CLT

Supervisor: 15 salários mínimos + CLT

Coordenador TI: 20 salários mínimos + CLT

Escolher a Tecnologia (Inovação) / e o porquê da escolha 03 critérios / justificativa.

Fazer uma licitação/tomada de preço para uma empresa disponibilizar todos os recursos necessários porque assim fica mais barato, a empresa irá prestar o suporte, vai distribuir os recursos quando a empresa necessitar e também pode prolongar o vínculo sem a necessidade de nova licitação/tomada de preço.

Parque Tecnológico

Computadores com configuração básica: 01 Giga de memória RAM, Ambiente Windows / Linux (definido no Estudo de Viabilidades), Antivírus, Softwares para auxilio no atendimento, infra-estrutura e instalações de acordo com a ISO.

Custos (por profissional, tecnologia, infra-estrutura, formação da equipe)

Esses custos serão todos terceirizados e de acordo com as ISOs.

Tempo

Terá um início estipulado pela necessidade dos clientes, um desenvolvimento e fim quando tudo estiver ordenado e todos os recursos funcionando.

Áreas do Conhecimento (PMBOK – 9 +1(no mínimo)).

PRAZO	AQUISIÇÕES	COMUNICAÇÃO
CUSTO	INTEGRAÇÃO	RISCOS
RH	QUALIDADE	ESCOPO
POLÍTICA (melhor relacionamento com cliente)	TREINAMENTO (para atender os clientes com maior destreza, cordialidade e conhecimento dos aplicativos)

Patrocinadores.

Neste caso a empresa citada é a CASSI, seria a Diretoria da Empresa.

Mas pode ser implementada em outras empresas como: Empresas de TI, Empresas de Telecom, Fábrica de softwares, Empresas de Marketing, etc.

Projetando: O Escopo de Projetos

alexandrecreis — Wed, 29 Sep 2010 21:08:21 +0000

Para falar sobre Escopo, ou seja, sobre o trabalho a ser feito em um projeto, sempre é bom lembrar que antes do projeto propriamente dito é comum ainda ser realizado um estudo de viabilidade para o mesmo ser formalizado, onde é feita uma análise sobre todas as variáveis que circundam o seu contexto a fim de determinar pontos fortes e fracos que levariam a realizar o projeto em questão.

O Escopo de um projeto é onde se descreve o que se quer como solução, produto ou serviço e, por isso, precisa ser precisamente delineado para que, através dele, o trabalho tenha uma referência por onde será conduzido.

O gerenciamento do escopo do projeto inclui os processos necessários para garantir que o projeto inclua todo o trabalho necessário, e somente ele, para terminar o projeto com sucesso e trata principalmente da definição e controle do que está e do que não está incluído no projeto.

Como já foi dito sobre o ciclo de vida do gerenciamento de projetos , este descreve um conjunto de processos que devem ser seguidos para que o projeto seja bem gerenciado, os quais são Iniciação, Planejamento, Execução, Monitoramento ou Controle e Encerramento.

Todo processo de gerenciamento definido para as 9 áreas do guia PMBOK pertence a um grupo de processos do ciclo de vida do gerenciamento de projetos.

Os Processos de Gerenciamento de Escopo e o grupo de processos do ciclo de vida do gerenciamento de projetos ao qual pertencem, na versão atual do PMBOK são:

Planejamento do escopo – Planejamento – criação de um plano que documenta como o escopo do projeto e a EAP (Estrutura Analítica do Projeto) serão definidos e controlados.
Definição do escopo – Planejamento – criação de uma declaração do escopo detalhada do projeto.
Criar EAP – Planejamento – subdivisão das principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
Verificação do escopo – Monitoramento e Controle – formalização da aceitação das entregas do projeto terminadas.
Controle do escopo – Monitoramento e Controle – controle das mudanças no escopo do projeto.

A boa prática diz que uma declaração do escopo do projeto deve considerar os seguintes itens:

Objetivos do produto e do projeto;
Características e requisitos do produto ou serviço;
Critérios de aceitação do produto;
Entregas e requisitos do projeto;
Restrições do projeto;
Premissas do projeto;
Organização inicial do projeto;
Riscos iniciais definidos;
Estrutura Analítica do Projeto – EAP ou WBS – Work Breakdown Structure);
Estimativa aproximada de custos;

Fonte:

Helson Costa, http://gerenciapratica.blogspot.com/

Código de Ética e de Conduta Profissional do PMI

alexandrecreis — Thu, 23 Sep 2010 01:06:14 +0000

A obra

Código de Ética e de Conduta Profissional do PMI.

O conteúdo

Este Código de Ética e de Conduta Profissional tem como propósito estimular a crença na profissão de gerente de projetos e ajudar os profissionais a se tornarem melhores executores da profissão. Estabelecendo um amplo entendimento do comportamento profissional apropriado e altos padrões para nós mesmos e aspiramos encontrar estes padrões em todos os aspectos das nossas vidas – no trabalho, no lar e no serviço da nossa profissão.

Analise

A ética ilumina a consciência humana, sustenta e dirige as ações do homem, norteando a conduta individual e social. Define o que é virtude, o que é bom ou mal, certo ou errado, permitido ou proibido, para cada cultura e sociedade.

O Código de Ética traz a união de temas que tratam de regular os deveres de todos aqueles que estão subordinados a uma empresa, com relação aos superiores hierárquicos, entre os funcionários, deveres com relação aos clientes ou aos concorrentes da empresa em que trabalham. Estes deveres relacionam-se, diretamente, aos aspectos de urbanidade e de respeito para com o próximo e, como se trata de normas sobre disciplina, o estabelecimento de sanções pela indisciplina também se torna necessário, tanto com finalidade preventiva, como repressiva e punitiva.

Em um primeiro momento, o fato do tema “Código de Ética e de Conduta Profissional” estar fora do PMBOK poderia causar entranheza ou algum tipo de desconforto aos leitores mal avisados, pois permite uma equivocada e precipitada conclusão de que o PMI estaria atribuindo baixa prioridade para assunto tão importante.

Indiscutivelmente, a ética permeia todas as atividades de um gerente de projetos, para qualquer tipo de projeto, em qualquer uma das nove disciplinas mencionadas. Na realidade, a ética está presente (ou deveria estar) no dia a dia de todas as pessoas, no exercício de nossas atividades profissionais ou pessoais, na escola, no trabalho, no clube, no trânsito, nos negócios, no cinema, na rua, enfim, a ética deveria ser o oxigênio levado a cada célula do organismo humano, dando-lhe vitalidade, saúde moral e direcionando as ações de empresários, políticos e cidadãos.

Retomando o tema de gerenciamento de projetos, em todas as nove áreas do conhecimento (disciplinas), a ética está presente. Por exemplo, no gerenciamento da comunicação, cabe ao gerente do projeto: elaborar/acompanhar o Plano de Comunicação do Projeto e distribuir a informação para os interessados no projeto. No entanto, é inerente à sua atuação nesta disciplina que ele seja ético, dizendo a verdade e sem postura de “omissão por conveniência” diante de situação desfavorável do projeto ou de seus resultados.

Quatro valores importantes são os pilares do código de ética do PMI: responsabilidade, respeito, justiça e honestidade. O código de ética traz padrões de comportamento desejáveis que buscam nortear os profissionais dentro e fora da empresa.

Este Código de Ética e de Conduta Profissional descreve as expectativas que temos de nós mesmos e de nossos colegas profissionais praticantes e participantes da comunidade global de gerenciamento de projetos. Articula os ideais que desejamos, bem como os comportamentos que são obrigatórios na nossa profissão e no papel de voluntários.

O propósito deste código é fomentar a crença na profissão de gerente de projetos e ajudar os profissionais a se tornarem melhores executores da profissão. Faremos isso, estabelecendo um amplo entendimento do comportamento profissional apropriado. Acreditamos que a credibilidade e a reputação da profissão de gerente de projetos é formada pela conduta coletiva dos indivíduos que exercem a profissão.

Acreditamos que podemos promover nossa profissão, tanto individualmente quanto coletivamente, adotando este Código de Ética e de Conduta Profissional. Além disso acreditamos que este Código de Ética nos ajudará a tomar decisões mais sábias, particularmente quando estivermos diante de situações difíceis onde nós podemos ser questionados a comprometer nossa integridade ou os nossos valores.

Todos têm que ser responsáveis pelas decisões tomadas ou aquelas que deixaram de ser tomadas e as conseqüências que elas podem gerar.

Dentro do Código de Ética o respeito é fundamental e é exercido através da consideração que temos por nós mesmo, pelas pessoas que nos cercam em nosso ambiente de trabalho e pela clientela na qual atendemos.

A conduta ética gera urna visão de perspectiva que provoca um natural desejo de antecipar-se,de ter iniciativas para atender às necessidades da empresa e das pessoas que nela convivem, como fruto de sua sensibilidade ética. Algumas pessoas exercem influência ética sobre outras, orientam sua conduta, são capazes de conduzi-las. São os líderes.

As empresas têm desenvolvido métodos diversos para avaliar o perfil ético, mas ainda há muito a ser pesquisado nesse campo. A questão ética da contratação não se encontra no erro técnico ou na imperfeição dos instrumentos de avaliação do candidato. O problema ético real consiste em deixar de contratar, intencionalmente, a pessoa considerada ideal, ou ao contrário, contratar alguém, sabidamente não habilitado, para obter alguma vantagem significativa em troca.

É imprescindível estar sempre bem informado, acompanhando não apenas as mudanças nos conhecimentos técnicos da sua área profissional, mas também nos aspectos legais e normativos.

Recomendação da obra

Uma obra importante O Código de Ética e Conduta Profissional poderia e deveria ser divulgado aos alunos dos cursos de graduação e pós-graduação em Gestão de Projetos, para reforçar a seriedade e compromisso dessa comunidade, buscando envolvê-los na reflexão individual e coletiva sobre os padrões de conduta desejáveis e obrigatórios estabelecidos neste Código.

Fontes:

Código de Ética e de Conduta Profissional do PMI, Traduzido para a língua portuguesa do texto “PMI CODE of ETHICS and PROFESSIONAL CONDUCT” Original em inglês publicado no Jornal PMI TODAY – edição de Dezembro de 2006. Tradução por Paulo Sergio E.de A. Moraes, PMP; 26 de janeiro de 2007.

As 6 habilidades do Gerente de Projeto

alexandrecreis — Sun, 19 Sep 2010 20:37:27 +0000

“É preciso ser sincero, honesto, transparente.

O líder tem de dar ao grupo o que ele precisa, não o que ele quer.

Tem de satisfazer às necessidades, e não os desejos.

É fundamental consquistar a confiança da equipe e conhecer seus limites.

Não interferir no poder do outro, deixá-lo trabalhar.

As pessoas precisam ser encorajadas.”

Carlos Alberto Parreira

Depois destas palavras sobre liderança, veremos que um bom Gestor de Projetos (GP) deve ser BLONDE:

1. Bom comunicador.

Tanto oralmente quanto por escrito, o bom GP deve ter grande habilidade para se comunicar,

transmitir e receber mensagens dos demais membros da equipe e dos interessados.

Comunicar é um processo bi-direcional: não basta enviar a mensagem, é crítico que ela seja recebida com precisão.

2. Líder, nada a ver com “chefe”, liderar é motivar, é mostrar como se fez pelo exemplo.

Por líder entende-se alguém que:
(1) tem um senso claro de missão a cumprir, com foco e comprometimento,
(2) serve de modelo ao personificar os valores que defende,

(3) seja capaz de ter empatia, saber se colocar no lugar do outro e

(4) seja orientado a resultados, de forma a ser admirado (e não temido) pelos liderados.

3. Organizado, sabe onde está cada informação quando precisa dela.

A organização permite indetificar rapidamente onde estão os dados necessários para a tomada de decisão.

Os mecanismos de busca textual tornam certos procedimento catalográficos menos importantes do que já foram.

Uma dica é usar os serviços de hospedagem de documentos online (como o Google Docs) para ter acesso aos

dados necessários relevantes a qualquer hora e de qualquer lugar.

4. Negociador, não ser um “tirano” ou um “fraco”.

Mas o que é negociar? O que você pensa quando está negociando?

Negociar é trocar algo de valor para mim por algo de valor para você.

Numa negociação, a percepção de valor é fundamental: o que é escasso para mim pode não ser para você.

Também é importante que o líder tenha como meta sempre o “ganha-ganha”, em que os dois lados ganham.

Na próxima negociação, ao invés de pechinchar tente extrair mais do outro lado pelo mesmo valor, para ele o serviço adicional que ele lhe prestará pode custar menos do que o valor que você iria pedir de abatimento e ambos saem satisfeitos. A alternativa é “eu ganhar em cima de você”, que traz ressentimentos e baixa produtividade.

5. Desembaraçado. O bom GP é pró-ativo e toma iniciativas por conta própria.

Pessoas tímidas podem ter dificuldade em abordar uma pessoa que esteja com desempenho fraco

para cobrar resultados. O GP não pode ter este tipo de auto-bloqueio, mas também não precisa ser

o cara mais popular, como o “rei da festa”. Ele precisa ter iniciativa para agir a partir dos dados de

desempenho coletados e sem o receio de ser mal recebido pelos demais interessados do projeto.

6. Ético. Respeitando as regras de conduta da profissão e as normas do grupo, o GP é respeitado por sua equipe.

Apesar de não termos tido bons modelos em nossos líderes políticos recentemente, a ética é importante.

É ela que nos protege da cobiça alheia desenfreada e dá chances a todos de competir. Sem ética, o grande quebraria o pequeno, o forte subjugaria o fraco e o mundo seria um lugar pior para todos, mesmo para os fortes e poderosos. Um bom princípio ético nos foi legado pelo filósofo alemão Emanuel Kant:

“Haja como se suas ações fossem se tornar normas de conduta para todos”.

Um sábio colega me deu a sua versão:

“Haja de forma a poder explicar para a seus filhos o que você faz, sem passar vergonha”.

Conclusão

Uma pessoa que tenha todas estas habilidades costuma ser um bom GP.

Mas se isso não for possível e você tiver de escolher, provavelmente o mais importante aspecto seja o da liderança.

Fonte:

De autoria de Fernando C Barbi, PMP.

Conceitos Importantes

alexandrecreis — Sun, 19 Sep 2010 20:31:14 +0000

Os primeiros conceitos que você precisa conhecer são: Projeto, Risco, Escopo e Patrocinador.

Um Projeto é um empreendimento que se caracteriza por ser evento temporário e
ter um objetivo único e bem definido. O projeto não se confunde com tarefas rotineiras

de operação normal da empresa.

Quando ocorre esta confusão, o projeto corre riscos desnecessários.

Um risco é todo evento que pode impactar o projeto, para o bem e para o mau.

Se o risco pode é benéfico ao projeto, chama-se oportunidade.

Normalmente associamos a palavra “risco” a conseqüências negativas,

por isso uma das nove áreas de conhecimento recebe o nome de “Gestão de Riscos”.

Um risco constante é que sejam feitas alterações no escopo do projeto.

O escopo (scope) é tudo o que deve ser feito para se atingir o objetivo do projeto,
o que o projeto deve entregar.

Os entregáveis (deliverables) são documentos, protótipos e todos os demais

intangíveis (tais como treinamento e homologação) que o projeto deve entregar quando

for completado. Escopo não é “tudo o que o cliente quer” poque muitas vezes ele não

sabe tudo o que deve ser feito!

O GP deve alinhar o escopo com o patrocinador do projeto.

O patrocinador (sponsor) é quem apóia o projeto dentro da organização.
Pode ser um diretor que também autoriza os pagamentos, ou um gerente que
se reporta à diretoria, o importante é que ele ou ela apóie o projeto tanto
em termos financeiros quanto com respaldo político, garantindo os recursos

(verba e tempo do pessoal) quando necessário.

O patrocinador é um interessado (stakeholder) do seu projeto, assim

como são os membros da equipe que o executa, os usuários que como clientes

demandam o produto que o projeto deve entregar. Os terceirizados que
participam do projeto ofertando serviços para se fazer este produto também são

interessados. No caso de uma obra de engenharia civil que terá impacto na

vizinhança, como o caso de uma represa, os moradores do lugar afetado também

devem ser considerados como interessados e seus questionamentos devem ser

endereçados. Veja mais sobre Análise de Stakeholders.

Para que o projeto aconteça dentro de padrões previsíveis é preciso que parta

de uma metodologia de trabalho. A metodologia é o conjunto de processos,

documentos e regras para o desenvolvimento do trabalho. A empresa pode já dispor

de um conjunto de regras operacionais que o projeto pode usar para criar a sua

própria metodologia. O importante é que haja um conjunto formalizado de regras

de trabalho.

Também é importante formalizar os objetivos, intermediários e finais, do projeto.

São os marcos (milestones) do projeto: eventos de completamento de uma etapa.

Usa-se o conceito de marco para criar visibilidade dentro do processo. Atrasos na

entrega de um marco devem indicar problemas no projeto ou na sua condução, já

que esta deveria ter incorporado os atrasos ao planejamento, possivelmente revendo

também cronograma e orçamento.

Um cronograma (schedule) é uma sequência de datas de execução das tarefas necessárias para

a realização do escopo do projeto, listadas no WBS. O WBS (Work Breakdown Structure)

é o detalhamento de todas as atividades do projeto. Normalmente se faz numa planilha e fica

a cargo do responsável pela tarefa identificar todas as subtarefas que deve realizar para que

determinado objetivo seja atingido. O orçamento (budget) é a relação de custos associados às

tarefas especificadas no WBS.

Tanto o cronograma o quanto orçamento devem ter um baseline de referência.

O baseline é um modelo, um guia do que foi planejado já com todas as alterações

aprovadas. O benchmark é um tipo de baseline aceito na indústria como um padrão a

ser seguido. Para se chegar a um desempenho de benchmark, costuma-se seguir as melhores

práticas. As melhores práticas (best practices) é um conjunto de procedimentos

entendidos como ideais para realizar uma determinada atividade.

Quando uma mudança é solicitada, o GP deve verificar o impacto que terá sobre

o seu baseline. Se o impacto for significativo ele deve submeter o pedido de mudança

a um comitê de controle. O comitê de controle de mudança (change control board

ou CCB) é o grupo autorizado a estudar e aprovar as solicitações de mudança no projeto.

Este grupo pode ser composto apenas do patrocinador, se este tiver as condições para

assumir o ônus da mudança.

Numa empresa com maior maturidade em Gestão de Projetos costuma-se encontrar um PMO.

O PMO (Project Management Office) é um grupo que excerce desde funções de

treinamento e padronização das metodologias até efetivamente gerenciar os projetos.

A existência de um PMO indica um alto nível de maturidade da empresa em gerenciamento de

projetos uma vez que ela busca, ao estabelecer um PMO, otimização pelo compartilhamento

de recursos e aumento da qualidade da gerência pela especialização de funções.

Normalmente, num PMO cada profissional cuida de um determinado aspecto de todos os projetos

da organização, como finanças, planejamento, aquisição, pessoal, etc…

Fonte:

www.gestaodeprojeto.info

Algumas Questões – Parte IV

alexandrecreis — Sat, 04 Sep 2010 02:35:28 +0000

Fluxo Resumido de Processos do Gerenciamento de Projetos – Base: PMBOK 4ª Edição

1) Analisando o Fluxo de Processos do PMBOK 4ª Edição e descreva suas impressões.

Processo de Iniciação –

Podemos verificar um equilíbrio entre as áreas de conhecimento de integração e comunicações.

Processo de Planejamento –

Podemos verificar que a uma ampla definição de tempo e risco.

Processo de Monitoração e Controle –

Podemos verificar que neste processo praticamente todas as áreas de conhecimento aparecem, tendo um maior destaque para o escopo, pois este é neste que consta os objetivos do projeto.

Processo de Execução –

Podemos verificar que a uma ampla definição entre os recursos humanos e comunicações.

Processo de Encerramento –

Podemos verificar um equilíbrio entre as áreas de conhecimento de integração e aquisições.

2) Quais são as áreas de conhecimento?

As áreas de conhecimento de acordo com o PMBOK, são 9 (nove) e caracterizam os principais aspectos envolvidos em um projeto e no seu gerenciamento:

Integração;
Escopo;
Tempo;
Custos;
Qualidade;
Recursos humanos;
Comunicações;
Riscos;
Aquisições.

3) Quais são os processos do ciclo de vida de um projeto?

Os cinco processos de gerenciamento de projetos são:

Iniciação;
Planejamento;
Execução;
Monitoramento e Controle;
Encerramento.

4) Quantos são os processos do fluxo de gerenciamento de projetos?

De acordo com Metodologia PMI e o PMBOK, podemos afirmar que são ao todo 42 processos do fluxo de gerenciamento de projetos.

5) Além das nove áreas de conhecimento, pode haver outras em um projeto? Por quê?

Sim, pode com certeza haver outras áreas de conhecimento. Tudo depende da característica e natureza do projeto.

6) O que é um programa?

Programa é um grupo de projetos designados a alcançar um objetivo estratégico mais abrangente.

7) Quais os elementos norteadores de um programa?

Os elementos norteadores é o objetivo estratégico da Empresa, ou seja, as políticas e diretrizes da Empresa.

8 ) O que é um projeto e o que ele pode entregar?

Projeto é um empreendimento não repetitivo (único), caracterizado por uma seqüência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.

Um projeto pode e deve entregar tudo aquilo que foi definido no escopo, e o escopo é a magnitude do trabalho a ser desenvolvido.

9) O que é um portfólio?

Um portfólio é uma coleção de projetos ou programas que são agrupados para facilitar uma gestão mais eficaz destes empreendimentos como forma de atender os objetivos estratégicos de negócios da organização. Os projetos ou programas em um portfólio não necessariamente devem ser interdependentes ou estarem diretamente relacionados. Os recursos e suporte necessários aos itens de um portfólio podem ser atribuídos de acordo com os riscos/rendimentos envolvidos, linhas de negócios específicas ou alguns grupos gerais de projetos, tais como projetos de infra-estrutura ou processos internos de melhoria. As organizações controlam seu portfólio de acordo com objetivos específicos.

10) Que elementos constituem um portfólio?

Um portfólio é constituído por programas, projetos e subprojetos.

11) O que é um escritório de Projetos?

O conceito geral de um Escritório de Projetos, os famosos PMO’s, ou Project Management Office, nada mais é do que uma área dentro da empresa encarregada de acompanhar os projetos de maior importância para a organização com o objetivo de garantir a qualidade na realização dos mesmos.

Fonte:

http://pt.wikipedia.org/wiki/

www.ricardo-vargas.com

www.pmtech.com.br

Livros:

Use a Cabeça PMP; Andrew Stellman, Jennifer Greene

Implantando a Governança de TI; Aguinaldo Aragon Fernandes e Vladimir Ferraz de Abreu

O projeto mais antigo do mundo: Entenda o conceito de Projeto

alexandrecreis — Sat, 04 Sep 2010 01:20:25 +0000

Transcrevo abaixo uma das primeiras memórias sobre o conceito de Projeto, que ocorreu durante a primeira aula de um curso sobre Gerenciamento de Projetos. Após o professor ter apresentado todos os conceitos iniciais, um dos alunos fez o seguinte questionamento:

“- Professor, qual o projeto mais antigo da história?”

A resposta do professor, precedida de um questionamento, surpreendeu a todos:

“- Você acredita que Deus construiu o mundo em 7 dias?”

“- Acredito.” – foi a resposta do aluno.

“- Então, considere a Criação do Mundo como o projeto mais antigo da história.”

Enquanto alguns entenderam o diálogo como uma brincadeira entre aluno e professor, eu procurei identificar as características de projeto no projeto mais antigo do mundo. E isto é o que faremos agora.

Seguindo o conceito do PMBoK – se você não sabe o que é PMBoK, por ora entenda como a principal referência para iniciar o estudo de GP – um projeto é:

“Um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”.

Voltando o foco para a nossa análise, vamos primeiramente quebrar esta definição em duas partes, compará-las com o exemplo dado pelo professor e identificar duas características principais de um projeto.

1. “O projeto é um esforço temporário”

Segundo a tradição bíblica, Deus criou o mundo em 7 dias, portanto, foi um esforço temporário, encaixando-se com a definição de projeto apresentada pelo PMBoK. Ponto para o professor!

Apenas uma consideração, o adjetivo temporário não significa essencialmente que um projeto é um empreendimento curto; mas sim que projetos devem possuir – embora em alguns casos não pareça – uma limitação no tempo, ou seja, início e fim bem definidos.

Outra característica de projetos que pode ser extraída desta primeira “metade” da definição dada pelo PMBoK, está relacionada à palavra esforço, pois esforços são realizados essencialmente por pessoas e em alguns casos, por equipamentos.

As pessoas ou “coisas” que esforçam-se pelo projeto são tradicionalmente chamadas de recursos do projeto.

2. “O projeto é empreendido para criar um produto, serviço ou resultado exclusivo.”

Também segundo a tradição bíblica e usando um pouco de bom senso, sabemos que Deus não criou dois “Mundos” semelhantes; portanto o resultado final do trabalho foi extremamente único. Mais um ponto para o professor!

Esta é uma das maiores dificuldades para o profissional de Gerência de Projetos, pois como o produto final é único, o grau de incerteza dentro do projeto é extremamente elevado, e com isso, as chances de erro aumentam muito.

Além destas duas características, o PMBoK ainda apresenta mais uma característica principal de projetos, denominada Elaboração Progressiva, que integra as duas características anteriores, ao garantir que os projetos são construídos incrementalmente ao longo do tempo, ou seja, as entregas de uma fase anterior são necessárias para alguma fase seguinte.

Voltando aos relatos bíblicos, Deus teve o seu plano para construir o mundo, e seguiu uma ordem lógica para isto, construindo céu e terra no primeiro dia, as águas no segundo, e assim até chegar ao sétimo dia e o merecido descanso… Afinal, ele não poderia criar nenhum animal, sem que o ambiente estivesse pronto para recebê-lo. É o terceiro ponto do professor.

Independente de crenças ou religiões, este é um ótimo exemplo para explicar o que é projeto de uma maneira extremamente didática, pois tem um perfeito encaixe teórico e é um “case” já conhecido por todos.

Fonte: http://pmlog.wordpress.com/

Algumas Questões – Parte III

alexandrecreis — Sat, 28 Aug 2010 03:04:11 +0000

1) O que é uma tipologia de projetos?

Shenhar (2001) entendeu que não havia um modelo padrão para se gerenciar qualquer projeto, contrariamente ao sugerido por boa parte da literatura. Ou seja, diferentes tipos de projetos requerem diferentes formas de gestão (SHENHAR, 2001). Reforçam essa interpretação as diferentes possibilidades tipológicas existentes para os projetos com as suas decorrentes diferenças no gerenciamento. Então, a tipologia de projetos é uma maneira de classificar os projetos.

2) Qual a importância da tipologia de projetos?

É importante sim, pois de acordo com a tipologia dele iremos identificar se é necessário alterar as nove áreas de conhecimento para as particularidades especificas do projeto, bem como o estudo de viabilidade e recursos deste projeto tornam-se mais específico.

3) O que são Mega-Projetos?

Mega Projeto é um tipo especial de projeto. São projetos de grande magnitude, extremamente complexos, normalmente definidos como empreendimentos com orçamento muito alto (freqüentemente vários bilhões). Este tipo de projeto atrai um alto grau de atenção pública e interesse político por causa do imenso impacto direto e indireto que provoca na comunidade, no ambiente e nos orçamentos públicos e privados. Ex: Copa do Mundo.

4) O que é portfólio de Projetos?

5) Qual a relação entre estratégia e projetos?

É uma relação direta entre a estratégia e projetos, segundo um estudo realizado com 609 gestores de projetos, mostra que quanto mais as iniciativas estão alinhadas aos objetivos estratégicos da empresa, maiores as chances delas serem conduzidas com sucesso. No estudo, 77% dos entrevistados afirmam que os projetos têm conexão direta com a estratégia corporativa da empresa.

6) Cite exemplos de Projetos de porte Logístico?

Distribuição de medicamentos conforme as regras da ANVISA por todo o país (Ex. Rapidão Farma), Olimpíadas.

7) Cite exemplos de Projetos de tipologia de tecnologia?

Automatização de processos em uma micro-empresa.

8 ) O que são programas?

Programa é um grupo de projetos designados a alcançar um objetivo estratégico mais abrangente.

9) Cite as tipologias de projeto indicadas em aula?

- Por Natureza de conhecimento (Áreas específicas de conhecimento

- Complexidade (Mega Projetos)

- Porte Logístico (cadeia produtiva envolvida)

- Por Tecnologia (Industrial)

- Energia à Hidroelétrica (Vale do Rio Doce)

- Transporte à Aviões (Boeing/ AirBus)

- Saúde à Medicamentos (Shering)

- Por Custo à Gestão à Por demanda limitada à caixa;

- Por Resultado à Projetos pontuais

- Por Investimento à Agências de fomento (FINEP/CNPQ/BNDES/ANPROTEC/etc)

10) O que é escritório de Projetos?

Fontes:

http://www.excelenciaemgestao.org

http://www.administradores.com.br

www.cio.uol.com.br

www3.informazione.com.br/cms/…/rapidao/pt/…/informativo-nov2005.pdf