10 itens que matam a produtividade diária

Prezados Leitores, segue uma matéria muito interessante que retirei da HSM Online, módulo de recursos humanos muito interessante. Vale a pena ser lido!!

Reuniões, e-mails para responder, acúmulo de tarefas, cansaço. Tudo isso pode fazer com que você gaste mais tempo do que deveria em suas atividades.
Um planejamento semanal bem elaborado pode cair por terra quando as atividades diárias pré-estabelecidas são deixadas de lado por motivos circunstanciais ou urgentes, que atrapalham a produtividade. Será que você tem passado por isso? Confira a lista abaixo e veja com quais itens você se identifica.


1 – E-mail – Ficar com o e-mail aberto faz o nível de interrupções ficar intolerável, aumenta a ansiedade e a sensação de atividades por fazer. Recomendo definir períodos para lidar com as suas mensagens sendo que no resto do tempo o caixa deve ficar fechada.


2 – Não ter clareza sobre o que fazer – O que você precisa fazer primeiro? Você sabe pelo menos 80% do que deve ser feito hoje? Se não souber responder a essas perguntas, com certeza vai se perder em tarefas circunstanciais.


3 – Estou em Reunião – Uma pesquisa feita pela Triad Consulting, empresa dá qual sou diretor, demonstra que 1/3 das reuniões podem ser canceladas. Então: dieta de reuniões já! Quanto menos, melhor. Se tiver de fazer, seja objetivo, defina pontos de discussão e faça durar no máximo 2 horas.


4 – Redes Sociais – Você usa twitter, facebook, orkut, etc? Controle a ansiedade de ficar conectado a essas redes. Utilize eventuais intervalos no dia ou o horário de almoço para se atualizar.


5 – Falta de energia – Você está cansado, sem pique e não consegue se concentrar? A falta de “energia” rouba muitas horas do dia e faz a pessoa “surfar” em atividades circunstanciais. Tenha hobbies, procure um médico, tome um multi-vitamínico, alimente-se em horários regulares, faça sexo (com freqüência).


6 – Falta de foco – Começa uma atividade e em pouco tempo salta para outra tarefas? Se a atividade for grande, quebre em pequenas atividades, feche qualquer outro software que não esteja usando, coloque o celular no silencioso e, se funcionar para você, ouça música.


7 – Navegador cheio de favoritos – Você abre seu browser para ir em um site, esbarra na lista de favoritos e começa a surfar por outros portais? Instale um novo navegador (sugiro o Safari) e não importe os seus favoritos. No novo browser, com a lista de favoritos zerada, você perde a tentação de ficar navegando à toa.


8 – Messenger, Wave, GTalk, etc – A regra é simples: está ocupado? Fique com status invisível ou offline. Está tranquilo? Fique ausente ou ocupado. Está com tempo para conversar? Fique disponível.


9 – Interrupções – Se muita gente interrompe você, pode ser porque sua comunicação não anda muito adequada. Faça uma revisão de como redige os emails, concede informações e delega atividades.


10 – Tarefas imprevistas, convites inesperados e favores – Que tal falar NÃO de forma concreta (baseado em planejamento X disponibilidade)? Se muitas tarefas imprevistas surgem na sua rotina, é possível que o nível de planejamento não esteja adequado. Repare em quais dias da semana você tem mais imprevistos e utilize isso a seu favor.


Por Christian Barbosa (Especialista em administração de tempo e produtividade, é fundador da Triad PS, empresa multinacional especializada em programas e consultoria na área de produtividade, colaboração e administração do tempo. É Autor dos livros “A Tríade do Tempo", "Você, Dona do Seu Tempo”, “Estou em Reunião” e co-autor de “Mais Tempo, Mais Dinheiro”).

HSM Online

16/11/2009

Habilidades Humanas - SOFT SKILLS - de um Gerente de Projetos

Neste Post falo sobre as habilidades humanas - SOFT SKILLS - necessárias para um gerente de projetos. Este post é baseado em um podcast do Ricardo Vargas, chairman do PMI, que é uma autoridade no assunto, com diversos livros publicados.



Além das boas práticas inseridas no PMBOK que representam as habilidades gerenciais, chamadas de HARD SKILLS, envolvendo as áreas de conhecimento e fases dos projetos, o gerente de projeto tem de ter outras habilidades que podem ser chamadas de humanas ou SOFT SKILLS.

Estas habilidades estão descritas abaixo:

1. Liderança - O gerente de projeto deve sempre buscar ser um líder e não um chefe. Um líder busca sempre ser uma pessoa inspiradora que envolva os seus liderados, um chefe usa apenas da autoridade e o poder. O líder tem de ser uma pessoa motivadora e não autoritária. Deve usar a autoridade com responsabilidade.  Liderança envolve servir aos seus liderados para que eles realizem o seu trabalho também de forma inspiradora. Por outro não pode perder o controle sobre seu time, não pode perder a autoridade. O líder tem de demonstrar respeito e inspirar respeito.
2. Trabalhar em time - O gerente de projeto deve sempre buscar trabalhar em time e motivar seus liderados a trabalhar em time. Deve criar dentro do mesmo uma Sinergia porém sem deixar de incentivar a Diversidade. Um time que não tem uma forte Sinergia pode vir a ter problemas nos seus projetos. O gerente de projetos deve entender as expectativas de cada membro do seu time e passar para todos os valores e objetivos da organização a qual pertecem. O time deve entender os objetivos do projeto e o que se espera de cada um. O gerente de projeto deve trabalhar também com um time que tenha diversidade, motivar seu time para que manifeste suas opiniões e pontos de vista diversos. Sinergia e Diversidade devem ser equilibradas para o sucesso do time.
3. Gerenciar o poder - O gerente de projeto tem saber gerenciar o poder, utiliza-lo com equilíbrio. Evitar dar ordens ou usar o poder com terceiros sem ter a certeza que aquela ordem será obedecida ou respeitada. Usar da política, não no sentido pejorativo, muito comum nos dias de hoje, mas de forma a convencer de forma positiva que o caminho indicado por aquela ordem é o melhor possível.
4. Gestão de conflitos - Os conflitos em um projeto são essencias. Pode parecer espirito de porco, mas não é!!! Um projeto sem conflitos representa um projeto aonde a crítica construtiva não existe. Por outro lado, deve ser gerenciada a crítica destrutiva e os conflitos desagregadores. Em outro post anterior descrevi uma série de métodos de tratamento de conflitos. Vale a pena ler.
5. Gestão de stress - Assim como os conflitos os stress também é necessário, mas, de novo, o stress positivo. Você deve estar se perguntando: stress positivo??? Sim, um projeto sem pressão tende a cair na monotonia e na falta de objetividade. Devem ser criadas metas ou marcos (milestones) intermediários, colocar datas fixas e responsáveis por estas metas. Por outro lado o gerente de projeto é responsável por equilibrar o stress negativo, deve blindar o seu time e filtrar a pressão de modo a não "congelar" os membros da sua equipe. A equipe não pode ter um 'branco" por excesso de stress. Como diz aquela expressão em inglês: no pain no gain, isto é, não há ganho sem dor.
6. Atitude diante do risco - O gerente de projeto deve procurar sempre identificar, planejar, qualificar, quantificar e controlar os riscos do projeto, porém nem todos os riscos podem ser identificados, são chamados os unknow unknow risks, riscos que não podem ser previstos. Para isso é importante que o gerente de projetos tenha atitude perante a fatos imprevistos. Deve estar sempre pronto pra responder a estímulos externos da melhor forma possível. O gerente de projetos tem de ser quem nem mulher grávida: deve estar sempre esperando!!!
7. Persistência - Ser gerente de projetos não é fácil, tem de matar um leão por dia, porém ainda bem que não é fácil, por que se fosse fácil, nós não existiríamos. Se não tivéssemos de de ter liderança, trabalhar em time, gerenciar o poder, gerenciar os conflitos e o stress, e ter atitude não havia a necessidade de gerenciar nada apenas executar as tarefas e pronto. O desafio é que nos motiva, nos mantém vivos e felizes. Para isso é importante ter persistência para vencer os desafios do dia-a-dia.

Bem amigos leitores espero ter atendido a expectativa de todos e novamente me coloco a disposição para trocarmos idéias. Fique a vontade para comentar e discutirmos mais este post.
Abraços Marcelo Mendes.

Guia para elegibilidade para o PMP

Senhores segue um guia básico sobre a Elegibilidade para PMP.
Não Bacharel, porém com 2.grau completo:
Possuir experiência de no mínimo 5 anos em gerenciamento de projetos, durante os quais no mínimo 7500 horas foram liderando e dirigindo tarefas em projetos. *

Bacharel (ou grau universitário):
Possuir experiência de no mínimo 3 anos em gerenciamento de projetos, durante os quais no mínimo 4500 horas foram liderando e dirigindo tarefas em projetos. *

* Experiências há mais de 8 anos não serão consideradas

Atividades
Os candidatos são requisitados a comprovar e documentar sua experiência em realizar as tarefas nos seguintes domínios, como parte do processo de inscrição.
Devem ter sido desenvolvidas as seguintes atividades:
• Processos de Iniciação – Reconhecer que um projeto ou fase deva iniciar e comprometer-se a fazê-lo;
• Processos de planejamento – Elaborar e manter um esquema de trabalho viável para atingir as necessidades de negócio que o projeto foi planejado para endereçar;
• Processos de Execução – Coordenar pessoas e outros recursos para conduzir o que foi planejado;
• Processos de Controle – Garantir que os objetivos do projeto sejam atingidos, monitorando e medindo progresso e tomando ações corretivas quando necessário;
• Processos de Encerramento – Formalizar aceitação do projeto ou fase e conduzi-lo a um final organizado.

Como iniciar uma carreira de Gerente de Projetos

Prezados leitores hoje mudo um pouco o foco dos posts para escrever sobre um ponto que tenho sido bastante questionado: como iniciar a carreira de gerente de projetos.
Primeiro ponto que considero importante é a aptidão para gerenciar pessoas e projetos. Como você poderia saber se tem esta aptidão?? Você deve gostar, por exemplo, dentro do seu grupo de amigos e colegas a tomar a frente dos eventos que apareçam, como organizar aquele churrasco ou aquela pelada. Para as meninas organizar aquele chá de bebê ou uma reunião social. Estes são bons indicadores que você tem aptidão para a coisa. Outro ponto: na sua casa, você é aquele(a) que administra as contas. Este é outro bom indicador. No entanto, você pode desenvolver este "skill" com MBA ou cursos específicos sobre o gerenciamento de projetos.
Se você deseja dentro do seu grupo de trabalho desenvolver-se como Gerente de Projetos, converse com seu gerente e exponha isso para ele. Comece a trabalhar junto ao seu líder e procure iniciar com pequenos projetos ou demandas. Comece a estudar os processos da sua empresa.
Quando estiver iniciando a gerenciar pequenos projetos procure utilizar as boas práticas do PMI (Project Management Institute). Siga o PMBOK (Project Management Body of Knownledge) que contém estas boas práticas. Sugiro você se cadastrar no site e se realmente resolver que é isso que você quer, sugiro que você se torne membro do PMI.org.
A certificação PMP (Project Manager Profissional) do PMI é hoje considerada exigência mínima para se destacar no mercado. Porém você deve ser elegível para a certificação. Isto exige experiência em projetos comprovada, ter feito curso preparatório e passar por uma exigente prova de certificação do PMI.
Outro ponto é construir a sua network profissional e manter este contatos durante sua carreira. Uma das boas formas é através do Linkedin. Nele você deve montar um bom currículo e um perfil bem direcionado. Participar de grupos de discussão como Brasil: Vagas Executivas que contém muitas oportunidades e listas de discussões.
É essencial falar inglês o mais fluente possível, mas ai estou "chovendo no molhado".
Enfim amigos leitores, como tudo na vida exige bastante dedicação e amor pelo o que você faz. Se desejaram mais dicas e informações por favor deixem seus comentário que estou a disposição para ajudar nos seus primeiros passos.
Forte abraço.

Maturidade, profissionalismo e comunicação!

Pessoal vi esta matéria no site abaixo e resolvi replicar aqui por achar muito boa!!!
Vale a leitura!!!

Maturidade, profissionalismo e comunicação!

Publicado em 19/10/2009 por Bruno Soalheiro

http://ogerente.com/carreiraesucesso/2009/10/19/maturidade-profissionalismo-e-comunicacao/


Empresas que atuam e são competitivas no mercado, sejam elas nacionais ou multinacionais, são formadas por pessoas maduras, equilibradas, e que colocam constantemente o profissionalismo acima de quaisquer pirraças pessoais, correto?

Correto! Papai Noel também existe e o natal está quase chegando, façam seus pedidos.

É triste, mas fico cada vez mais impressionado com algumas atitudes que contrariam o mais básico do bom senso no ambiente profissional. Como gestor de RH, costumo ser o centro para qual convergem todos os problemas de relacionamento que, de uma forma ou outra, acabam se refletindo na produtividade da empresa.

Tudo bem, falo de gente com apenas 40, 50 anos de idade (cronológica), que “se esquece” de passar uma determinada informação a um certo colega, ou “atrasa” algum fluxo de trabalho por distração. O curioso é que a distração e o esquecimento são extremamente seletivos, e apenas atingem alguns determinados grupos ou pessoas.

De verdade, como psicólogo, ( e também como gestor de pessoas), sei que esperar espontaneamente bom senso das pessoas, é pedir demais; eu reconheço. Ainda assim, tem gente que faz cada coisa que é de levantar os cabelos!

Está certo também que muitas vezes as empresas não têm qualquer programa de gerenciamento de conflitos ou melhoria dos relacionamentos no ambiente de trabalho; mas mesmo assim não é de esperar que gente “crescida” sabote serviços por conta de algo como “fiquei de mal” ou disputas de cunho pessoal.

Mas deixando de lado as ironias, convido-o seriamente a refletir, seja como empregado ou gestor, sobre o que leva as pessoas a tomar tais atitudes e como agir para evitá-las. Algumas vezes – parece brincadeira – mas acontece até com a gente.

Olhar de fora uma situação é fácil, mas quando estamos envolvidos podemos vir a sabotar situações ou pessoas de forma tão velada que nem mesmo nós nos damos conta. E o mais impressionante é que a forma de resolver isto, seja em nós mesmos ou nos grupos que gerenciamos, é a mesma há centenas de anos: Comunicação honesta e assertiva!

Percepções são muitas vezes cristalizadas, e pessoas passam dias, meses, anos, pirraçando umas com as outras por simples falta de comunicação. Eu achei isto…. Eu pensava que… Fulano me olhou assim… Alguém me disse que o outro ouviu… E pronto, está formado o jardim de infância!

Já vi gente ser desligada de projetos por causa de atitudes infantis a ponto de quase saírem às “vias de fato”, quando a situação poderia ser resolvida a partir de comunicação serena e adulta.

Se a empresa na qual você trabalha não tem nenhum programa voltado à melhoria das relações interpessoais, faça uma sugestão para que o implantem; se nada for feito, tente garantir que pelo menos você, e quem estiver à sua volta, saiba contornar tais “animosidades” através de uma conversa sincera e bem orientada, antes de chutar, ou quem sabe “furar” o balde.

Promova a comunicação em seu ambiente de trabalho, senão, sinceramente, daqui uns dias alguém vai chegar perguntando pelo Gervásio do setor de logística e vão dizer: __ Ah sim, o Gervásio, ele ta ali… No canto… De castigo!!!

Gestão de Stakeholders

Continuando o post anterior estarei falando neste sobre a gestão de stakeholders.
Após a identificação dos stakeholders, documentação destes em template próprio (veja exemplo anterior no post sobre project charter) deve ficar claro através do cronograma, plano de comunicação, plano de riscos,  plano de dependência externa, atas de reunião (com cliente/patrocinador, gerente sênior e time) e outros planos que são relevantes na gestão dos stakeholders.
A gestão envolve principalmente estes documentos acima citados:

• No cronograma devem estar citados os momentos aonde serão feitas as reuniões com os envolvidos que influenciam no projeto. 
• No plano de comunicação as informações sobre frequência, meio de comunicação (telefone, email, reunião presencial, etc.), prioridade entre os envolvidos, plano de escalada dos problemas e issues, audiência (quais stakeholders envolvidos? gerente, time, setor de finanças, ...).
• No plano de riscos devem estar identificados os riscos dos stakeholders sobre o projetos, detalhando seus impactos e probabilidades dos mesmos ocorrerem, os planos de contenção, planos de contingência, as dependências externas, as prioridades, análise quantitativa, etc.
• No plano de dependência externas devem estar detalhados os acordos fechados com stakeholders, o risco associado a esta dependência, data do acordo, o owner, data de conclusão do acordo, o status do acordo (Ex.: Aguardando Plano, datas Fechadas/em acompanhamento, negociação de datas, fechado, etc.) e a documentação do acordo negociado (Indicar localização da documentação de formalização do compromisso de dependência entre as organizações).
• Atas de  reunião com os stakeholders talvez sejam um dos documentos mais importantes, nelas devem estar a documentação de tudo o que acontece durante a gestão dos stakeholders. É importante que estejam documentados o que foi discutido nas reuniões, pendências das reuniões anteriores, pendências da reunião atual (sempre identificando o responsável, data da conclusão da pendência e descrição da mesma), data da mesma, owner da reunião e uma descrição completa de revisão de todos os plano do projeto relevantes a aquela reunião e a aquele stakeholder.
  

O que é um Stakeholder?

Stakeholder é qualquer pessoa ou organização que tenha interesse, ou seja afetado pelo projeto.
A palavra vem de:

• Stake: interesse, participação, risco
• Holder: aquele que possui

Os primeiros stakeholders que imaginamos em um projeto são o Gerente de Projeto, o Patrocinador do Projeto, a Equipe de Projeto e o Cliente. Entretanto, na prática podem existir muitos outros:

• A comunidade
• Outras áreas da empresa
• Concorrentes
• Fornecedores
• Investidores e acionistas
• Governo
• As famílias da equipe de projeto

Além disso, cada projeto pode ter alguns stakeholders que sejam específicos para sua realidade, e que não se apliquem a outros projetos.
A importância de identificar os stakeholders é que além de serem afetados pelo projeto, eles podem ter uma influência direta ou indireta no seu resultado. Uma falha nesta identificação significará que o gerente de projeto não estará pensando nas necessidades de todos os envolvidos, e isto é um fator de risco para o projeto.
Posso dar dois exemplos simples:

Um projeto que envolve uma obra em via pública deve considerar as necessidades da comunidade que será afetada pelo barulho e pelos transtornos (mesmo que a obra seja em benefício da comunidade), ou será alvo de reclamações que poderão levar a atrasos no cronograma.

Dentro de uma organização, um projeto pode gerar um resultado que fortalece algumas áreas em detrimento de outras. Mesmo que estas áreas não participem do projeto, é importante entender as relações de poder envolvidas, já que os que serão afetados negativamente poderão tentar boicotar o projeto.

Ao mesmo tempo, o gerente de projeto deve ter cuidado em não procurar stakeholders por todos lados, ou ficará com um cenário difícil de gerenciar. Com um pouco de imaginação, pode-se considerar stakeholder até o vizinho do gerente de projeto que deixará de jogar futebol com ele no fim de semana porque o gerente terá que trabalhar!
Claro que isto foi um exagero, mas o importante é ilustrar que se deve ter um limite lógico para a identificação de quem afeta ou é afetado pelo projeto.
A partir da identificação dos stakeholders, deve-se preparar um plano de comunicação que garanta o fluxo da informação correta para cada um. No futuro escreverei mais sobre os stakeholders e como gerenciá-los adequadamente.

Diretamente do Professional Development Day em Nova York

Nesse podcast Ricardo apresenta os principais destaques do Professional Development Day promovido pelo PMI New York City Chapter. Ele aborda temas como gestão ágil de projetos, gestão de talentos, valor do gerenciamento de projetos e aspectos humanos relacionados aos projetos. Segue o link: http://www.ricardo-vargas.com/pt/podcasts/pdd_nyc/ 

Templates de Project Charter

Prezados leitores segue, conforme planejado a alguns posts atrás, o template de Project Charter. Este template é apenas um exemplo e não um padrão definido.
Hoje estes templates abaixo são disponibilizados por uma quantia irrisória para manutenção dos custos do site. Agradeço a sua colaboração e participação.

http://www.hotmart.com.br/show.html?a=M735368M

Segue também um template com um padrão de Proposta de Atendimento. Este template é apenas um exemplo e não um padrão definido.

http://www.hotmart.com.br/show.html?a=M735337M

Abraços.

Brasil Vagas Executivas

Amigos é com prazer que distribuo no meu blog a mensagem abaixo sobre o crescimento do grupo no Linkedin Brasil Vagas Eecutivas. 

Parabéns Uilson!!!

 http://www.linkedin.com/groups?gid=1312007&trk=hb_side_g 

15 mil profissionais no grupo Brasil: Vagas Executivas

.
Amigos, bom dia.

O grupo atingiu hoje a marca de 15.000 profissionais unidos em um mesmo objetivo.

Quando, em 20.11.2008, iniciei este grupo, pensava em unir pessoas que buscavam o mesmo que eu: uma oportunidade para demonstrar CONHECIMENTO, HABILIDADE E ATITUDE.

Jamais, naquele momento, pensei que estava dando início ao maior grupo dentro do Linkedin em lingua portuguesa e que conseguiria, em tão pouco tempo, ajudar um grupo de pessoas a atingir seus mais sinceros objetivos de vida.

Agradeço a Deus ter tido esse insight e a cada um de voces por acreditar e ajudar a fazer a diferença na vida das pessoas.


Posted By Uilson Fernandes

Escrevendo um Project Charter

Prezados leitores, venho falar hoje sobre um assunto muito procurado no meu blog e na internet que é como elaborar o Project Charter, sendo traduzido por alguns como Termo de Abertura do Projeto. Outros consideram como Proposta de Atendimento de Serviço de Projeto. Eu prefiro chamar de Project Charter ou Proposta de Projeto.
O Project Charter é o documento que autoriza formalmente o início do projeto. O termo de abertura do projeto concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades do projeto. Quem autoriza o início do projeto é o sponsor ou patrocinador, que é responsável por financiar o mesmo.
O termo de abertura do projeto, diretamente ou referenciando outros documentos, deve abordar as seguintes informações:

• Requisitos que satisfazem as necessidades, desejos e expectativas do cliente, do patrocinador e de outras partes interessadas;
• Necessidades de negócios, descrição de alto nível do projeto ou requisitos do produto para o qual o projeto é realizado;
• Objetivo ou justificativa do projeto;
• Gerente de projetos designado e nível de autoridade atribuída;
• Cronograma inicial com os milestones sinalizados;
• Influência dos stakeholders;
• Organizações funcionais envolvidas, suas dependências e sua participação;
• Premissas organizacionais, ambientais e externas;
• Restrições organizacionais, ambientais e externas;
• Caso de negócios justificando o projeto, incluindo o retorno sobre o investimento;
• Orçamento sumarizado;
• Plano de Riscos sumarizado;
• Plano de Qualidade resumido;
• Devem estar descritos os papéis e responsabilidades de cada stakeholder envolvido.

Para a elaboração do Project Charter é necessário que esteja definido entre as partes envolvidas o SOW (Statement of Work) ou Declaração do Trabalho e, caso seja aplicável, um contrato entre as partes.

No SOW devem estar definidos:

• a necessidade de negócios: que pode se basear em: treinamento necessário, demanda de mercado, avanço tecnológico, requisito legal ou norma governamental;
• Descrição do escopo do produto: documenta os requisitos do produto e as características do produto ou serviço para os quais o projeto será realizado;
• Plano estratégico – todos os projetos devem dar suporte às metas estratégicas da organização.

Além disso, devem ser respeitadas a cultura, estrutura da empresa e todos os fatores ambientais aonde a empresa está inserida.
Outro fator são os ativos da organização como políticas, procedimentos, planos e diretrizes formais e informais cujos efeitos devem ser considerados.

Estarei no próximo post detalhando mais este processo e colocando um exemplo no formato de template.
Forte abraço.

Diferença entre funções do PMO e do Gerente de Projetos

Amigos anexo a seguir um Podcast do Ricardo Vargas sobre a diferença entre o papel do PMO e do gerente de projetos. Muita gente acha que a função de gerenciar o projeto é a função do PMO. Engano. Ricardo Vargas procura fazer uma analogia com um carro andando em uma estrada para explicar melhor a função do GP e do PMO. Ele faz uma relação entre a estrada, o motorista e o painel de instrumentos. Espero que gostem.
Segue o link:
Differentiating the Functions of the Project Manager and the Project Management Office

Sunscreen

Gerenciamento de Conflitos

Prezados amigos gerentes de projeto, vou escrever sobre um assunto que incomoda todo gestor de projetos: a gerência de conflitos. Todo bom gerente de projetos tem ciência que todo projeto inevitavelmente tem sempre mudança e conflitos pois envolve seres humanos. Nós somos seres inquietos e sempre insatisfeitos além de sermos sempre muito competitivos. Além disso tudo é impossível unir no mesmo time pessoas com a mesma opinião. Desta forma devemos esperar, como foi dito acima, alguns conflitos entre os stakeholders envolvidos no projeto.

Descrevo algumas boas técnicas e procedimentos que podem ajudar a resolver os conflitos. O gerente de projetos deve:

• estudar o problema existente e coletar toda informação disponível;
• desenvolver uma abordagem ou metodologia;
• conhecer bem a organização e seus membros;
• ouvir e entender antes de tomar alguma decisão ou avaliação;
• esclarecer a origem do conflito;
• entender os sentimentos dos envolvidos;
• sugerir procedimentos para resolver as diferenças;
• manter o relacionamento e o clima entre as partes envolvidas na dispulta do conflito;
• ser um facilitador no processo de comunicação;
• principalmente, buscar as soluções.

Formas para agir diante de conflitos

Existem 5 formas para agir diante dos conflitos:

1. Colaboração
   
2. Comprometimento
3. Acomodação
   
4. Imposição
5. Evitar o conflito

Na colaboração, as partes envolvidas são convidadas a participar de uma reunião face-a-face porém preparadas para trabalhar em conjunto numa solução comum. Nesta abordagem o foco tem de ser a resolução do problema e não na competição sobre a solução. Um processo de identificação da causa do conflito através do diagrama e do estudo de Ishikawa (diagrama de causa e efeito) se faz bastante interessante. Este método deverá ser usado nas seguintes situações:

• quando existe confiança;
• quando a idéia é reduzir custos;
• quando ambas as partes tem skills complementares;
• quando as duas partes querem buscar uma solução que seja boa para ambos ("win-win");
• quando o objetivo final é o mesmo e os desejam aprender algo novo.

No comprometimento, o que acontece é a barganha aonde ambas as partes saem com algum grau de satisfação, porém nem sempre totalmente satisfatória. Não se tem todas as necessidades atingidas porem o conflito é resolvido. Comprometimento deve ser usado:

• quando a outra parte é teoricamente mas forte que a sua parte;
• quando se deseja manter o relacionamento com a outra parte;
• quando você não tem certeza se está certo;
• para evitar a impressão de intransigente.

Na acomodação, a abordagem é a tentativa de reduzir as emoções que existem em um conflito, isto é realizado enfatizando as áreas de acordo em detrimento as em desacordo. No dito popular é como "colocar panos quentes" no conflito. Você concorda com alguns pontos e mostra que não está necessariamente em desacordo com os outros colocando "panos quentes" nos mesmos. Não obrigatoriamente a acomodação resolve o conflito mas tenta convencer as partes envolvidas em manter a negociação porque a solução pode ser possível.  Acomodação pode ser usada nas seguintes situações:

• para atingir um objetivo global;
• para criar uma obrigação de uma negociação posterior;
• para manter a harmonia;
• quando busca alguma solução que seja adequada;
• para criar um clima de boa vontade;
• para ganhar tempo.

Na imposição, uma das partes impõe a sua vontade para as outras. Normalmente acontece quando a resolução do conflito não ocorre nos níveis hierárquicos mais baixos e o "issue" é escalado para níveis superiores que tomam uma decisão definitiva e que normalmente atende apenas a uma parte do conflito. A imposição pode ser usada:

• quando se tem certeza que está certo;
• quando existe uma situação sem saída negociável;
• quando princípios estão em jogo;
• quando você é mais forte que a outra parte;
• para ganhar poder o status dentro da organização;
• quando o relacionamento não é importante;
• quando uma decisão rápida se faz necessária.

 Evitar o conflito é frequentemente considerado como uma solução temporária. Evita-se a situação fugindo do conflito e adiando a situação, porém o mesmo pode acontecer novamente várias vezes. No dito popular é o famoso "tirar o seu da reta". Evita-se o problema e adia-se a solução, porém o mesmo continua presente e demonstra por parte dos envolvidos a falta de responsabilidade. Evitar o conflito pode ser usado:

• quando você acredita que não vai ganhar o conflito;
• quando o que está em jogo é sem importância;
• quando o que está em jogo é alto, porém não se está preparado ainda para enfrenta-lo;
• para ganhar tempo;
• para enervar o oponente;
• para preservar a neutralidade ou reputação;
• quando acredita-se que o problema será esquecido;

Migrações de Sistemas

Amigos leitores, vou falar um assunto que sempre atormenta muitos gerente de projetos durante sua vida em tecnologia da informação: migração de sistemas.
Eu atuei em alguns processos de migração como mudança de servidor aonde o código é mantido, alterado, compilado e gerado, como foi o caso do CSP, em alta plataforma (mainframe) para Visual Generator (visualgen-baixa plataforma). Outra forte migração foi a alteração de um sistema da base de IMS (base de dados da IBM mais antiga) para DB2 (banco de dados relacional mais atual) ambos em mainframe. O terceiro foi de COBOL Microfocus (cliente-servidor)para COBOL/DB2 no mainframe, aonde o gerente que atuou no projeto na época (eu era coordenador neste período) aceitou o argumento do cliente que seria somente um "copy/paste", isto é, simplesmente copiar e colar sem ter de alterar nada. Doce ilusão!! ... ou melhor AMARGA ILUSÃO!!!!

Vou descrever abaixo algumas sugestões e dicas utilizando estas situações citadas e reais para evitarmos ou pelo menos mitigarmos as situações citadas.


Definição do escopo





Um dos pontos mais importantes, senão o mais importante, é definir o escopo da alteração. Se faz necessário definir o que será feito, pois nunca é somente um "copy/paste" existem sempre módulos obsoletos, novas necessidades e acertos na migração pertinentes a nova linguagem, novo banco de dados ou interfaces com o usuário.
Deve ser levantado, escrito e aprovado pelo usuário este escopo e é importante deixar claro o que vai ficar de fora do escopo da migração. Desta forma o gerente de projeto fica calçado e com provas do que está aprovado para ser feito evitando o "scope creep", que pelo PMI, significa descontrole na definição do escopo causando atraso no projeto, estouro nos custos do mesmo e insatisfação do cliente. Outra prática importante citada no PMBOK é evitar o "gold plating", isto é, fazer aquele algo mais para agradar o cliente. Evite fazer o que não está no escopo pois este "a mais" custo tempo e dinheiro e não foi pedido.
Outro ponto importante não é considerar somente o escopo do projeto em termos de lógica de programação ou requerimentos solicitados pelo cliente mas também definição de requerimentos físicos como banco de dados, servidores, volume de dados, taxa de crescimento de dados, incompatibilidade de banco de dados ou sistemas operacionais e por ai vai.
Obviamente existem várias outras questões a serem abordadas. E tudo precisa ser feito aqui nesta fase de definição de escopo, que é onde o custo ainda é mínimo e o impacto, se acontecer algo errado, será menor.

Plano de Riscos



Durante a fase de definição de escopo e levantamento dos requerimentos acima é importante iniciar em paralelo o levantamento dos riscos do projeto. Devem ser levantados os riscos de cada requerimento, das alterações e suas possíveis consequências. Alguns riscos que podem surgir:

• falta de um especialista nas ferramentas existentes;
• usuário não tem a definição clara de suas necessidades;
• falta de um usuário dedicado ao projeto em suas fases críticas (por exemplo, levantamento e testes);
• falta de um estudo de viabilidade do projeto;
• objetivos não estão claros;
• time de projeto desconhece o sistema ou ferramentas;

Importante entender o que é risco: ele representa o impacto de um problema caso ele vai a acontecer em um projeto versus a probabilidade do mesmo acontecer.
Os riscos devem ser definidos, qualificados, quantificados e definidos os planos para mitiga-los (antes para evitar que ocorra) e para contingencia-los (caso ocorra, o que deve ser feito).
Toda dependência externa do projeto deve gerar um risco, por exemplo a dependência de um fornecedor externo ao projeto.
Falarei sobre riscos em detalhes em outra oportunidade.

Planejamento da Migração



Faça todo o planejamento necessário para a migração, GASTE TEMPO PLANEJANDO. Evite sair executando. Documente os acordos, busque aprovação dos requerimentos, crie um cronograma, planilha de custos, plano de qualidade, plano de configuração, plano de mudanças, plano de comunicação e plano de recursos humanos. Crie um database estruturado aonde vai manter estes dados, de preferência uma ferramenta já consagrada e execute backup diários dos mesmos.
Em outros posts entrarei em maiores detalhes mas abaixo falo de alguns essenciais e mais específicos para a migração.

Plano de configuração

Deve ser bem controlada a configuração dos módulos que serão alterados, para isso um plano específico para migração deve ser criado com bastante critério, evitando passar para produção módulos incorretos. Utilizar algo como um software próprio, como o Rational Clearcase ou em caso contrário uma planilha. Neste caso deve ter um responsável como o coordenador do projeto (Team Leader) ou um analista de configuração.
Segue abaixo um modelo que já utilizei e serviu perfeitamente:

• criar uma versão inicial como 1.0.0, que é a copia do atual em produção
• a partir deste criar versões em ambiente de teste da migração como 1.0.1, 1.0.2...
  
• caso exista algum alteração em produção a mesma deve refletir no ambiente de teste da migração e sua versão passaria a ser 1.2.0
• a partir deste criar versões em ambiente de teste da migração como 1.2.1, 1.2.2...
• quando for passar para produção a verrsão de migração para produção teremos a versão 2.0.0

Cada módulo deve ser controlado e versionado. Devem ser mantidas as versões com final zero durante todo o projeto e se possivel algumas versões intermediárias.
Este é apenas um exemplo. Cada gerente pode criar seu modelo mas ele DEVE EXISTIR E SER BEM CONTROLADO pro um ÚNICO RESPONSÁVEL.


Plano de mudanças

Deve existir um plano claro de mudanças bem estabelecido e aceito pelos integrantes do time do projeto, usuário e principalmente pelo "sponsor", isto é, patrocinador do projeto.
Qualquer mudança no projeto deve ser analisada, avaliada, planejada e aprovada pelo "sponsor" ou pelo ele deve estar ciente da mesma. Todos os planos precisam ser refeitos e os impactos mensurados. Não deve ser aceito aquele famoso: "só vai alterar uma linha!!!"

Faça Backup

FAÇA BACKUP ! FAÇA BACKUP ! FAÇA BACKUP ! Sempre tenha um backup em mãos. Isto pode salvar muitas vidas. É sério !

Antes de começar o procedimento, faça cópia de tudo. TUDO MESMO ! Banco de dados, pasta dos aplicativos, executáveis, TUDO ! De preferência em duas cópias, porque backup é mestre pra não funcionar quando você mais precisa dele.

E não adianta comprar um CDzinho vagabundo na esquina. Ouça: NÃO ECONOMIZE neste ponto ! Os dados que você pode perder são de valores incalculáveis.

E não vale também fazer backup e guardar dentro da própria máquina. Os motivos eu não preciso nem explicar.

Crie uma base de testes

Não faça a migração em plena base oficial (ambiente de produção). Então, simule tudo em um ambiente o mais fiel possível do real. Se for um ERP, Crie um banco de dados de teste, use os executáveis que estão em produção. Assim você terá como corrigir alguns erros que irão ocorrer na sua migração oficial, antes mesmo que ela ocorra, diminuindo assim o tempo em que a empresa ficará sem utilizar o sistema.

Devem ser feitos os casos de teste e plano de testes bem claros. Os Casos de testes devem ser feitos pelo analista e pelo cliente em parceria, pois o cliente tem ciência das funcionalidades e o analista os detalhes do código e da base de dados. O Plano de Teste deve detalhar quais testes serão necessários, quem são os responsáveis envolvidos e suas datas.

Devem ser feitos 4 tipos de testes:

1. testes unitários, aonde o programador após a terminar o código faz testes básicos porém consistentes, evitando erros definidos nos requerimentos, de ambiente, de banco de dados e por ai vai;
2. testes de sistemas, aonde é feito os testes dos módulos completos;
3. testes integrados são os famosos "end-to-end", envolvendo todos os módulos do projeto;
4. testes de usuário, aonde somente neste momento o usuário é envolvido para testar as funcionalidades a serem implantadas e também devem ser "end-to-end"

Deve ser gerado um log de defeitos encontrados e corrigidos e caso exiga alguma alteração no escopo do projeto, a mesma deve ser submetida a Gestão de Mudanças.

Aceite pelo usuário

O aceite pelo usuário deve ser formal. Após obter o aceite busque o aceite do "sponsor" e certifique para eles que os mesmos são os responsáveis pelo sistema. Somente com este aceite você pode passar para produção.

Passagem para produção

A passagem para produção deve ser feita com muita cautela e se possível em várias ondas, por exemplo, primeiro a criação do banco de dados e carga do dados, segundo rotinas de backup e outras menos essenciais, terceiro módulos on-line. Deve ser separado para o projeto um período de tempo para a estabilização do projeto em produção. Durante este período sempre existe algum stress pois ai estamos trabalhando no mundo real e o cliente precisa naquele momento que o sistema agora em produção esteja funcionando corretamente.
Após estar tudo certo busque o aceite final do projeto com o sponsor e repasse o projeto para o time de manutenção oficialmente, isto é, de forma formal.
Projeto terminado, é a hora de gerar as lições aprendidas e as métricas, ambos coletados em tempo de execução do mesmo. É tempo também das atividades de fechamento de contratos e liberação dos recursos.

Boa sorte e bons projetos!!!

Vejam o link abaixo sobre generalistas X especialistas muito interessante para carreira de gerente de projetos.
Acompanhem o video e deixem suas impressões.
http://idealtv.uol.com.br/midiacenter/Generalistas-X-Especialistas-226b2a77c7f8540f8e2a22c03a775d33-776

Algumas considerações antes de seguirmos em frente

Gostaria de colocar algumas considerações antes de entrarmos nos próximos processos de gerenciamento de projetos que fogem um pouco da estrutura consagrada do PMI, porém muito aplicada por mim em projetos CMMI aonde a prática levou a adaptação das boas práticas do PMI dentro do modelo CMMI.

Pelo PMI, na inicialização são executados somente os processos de desenvolvimento do Project Charter e a Declaração do Escopo Inicial, porém no dia-a-dia estes dois documentos são insuficientes para uma análise executiva de GO/NO GO do projeto, isto é, se o projeto será aprovado pelo Sponsor, Gerente Sênior de Projeto e outros stakeholders diretamente ligados a aprovação do projeto.

Desta forma incluo algumas etapas da fase de Planejamento na fase de construção da Proposta.

Veja a seguir algumas etapas importantes:

1. para a fase de Inicialização, é importante o Gerente de Projeto gerar os seguintes documentos para planejamento e controle desta fase: Cronograma, Planilha de Custo, Plano inicial de Configuração, Plano inicial de Qualidade, Plano inicial de Comunicação e ter um database aonde esta documentação será armazenada com segurança.
2. após gerar os documentos deve ser executada uma inspeção dos mesmos que serão entregues ao cliente para evitar possíveis defeitos nos mesmos ("peer-review"), falaremos deste processo mais a frente.
3. Após gerar os documentos de requerimento e ter aprovação do cliente deste requerimentos, sugiro gerar os seguintes artefatos do projeto, além dos citados anteriomente: Plano de Recursos Humanos, Infra-estrutura e Recursos Computacionais Críticos, Plano de Riscos, rever o WBS do projeto, Cronograma, Sumário de Estimativas, Plano de Testes inicial, Plano de Dependências Externas.

Acredito que com esses artefatos em mãos o gerente de projetos terá como gerar um Project Charter mais completo.

Falaremos sobre cada um destes documentos e processos mais a frente.

Desenvolvimento do Plano de Gerenciamento do Projeto

O processo Desenvolver o plano de gerenciamento do projeto, pertence a fase de Inicialização, na área de conhecimento de Integração, e inclui as ações necessárias para definir, coordenar e integrar todos os planos auxiliares em um plano de gerenciamento do projeto. O conteúdo do plano de gerenciamento do projeto irá variar dependendo da área de aplicação e complexidade do projeto. Esse processo resulta em um plano de gerenciamento do projeto que é atualizado e revisado por meio do processo Controle integrado de mudanças. O plano de gerenciamento do projeto define como o projeto é executado, monitorado, controlado e encerrado. Esse plano documenta o conjunto de saídas dos processos de planejamento do Grupo de processos de planejamento e inclui:

• Os processos de gerenciamento de projetos selecionados pela equipe de gerenciamento de projetos
• O nível de implementação de cada processo selecionado
• As descrições das ferramentas e técnicas que serão usadas para realizar esses processos
• Como os processos selecionados serão usados para gerenciar o projeto específico, inclusive as dependências e interações entre esses processos e as entradas e saídas essenciais.
• Como o trabalho será executado para realizar os objetivos do projeto
• Como as mudanças serão monitoradas e controladas
• Como o gerenciamento de configuração será realizado
• Como a integridade das linhas de base da medição de desempenho será mantida e utilizada
• A necessidade e as técnicas de comunicação entre as partes interessadas
• O ciclo de vida do projeto selecionado e, para projetos com várias fases, as fases associadas do projeto
• As principais revisões de gerenciamento em relação a conteúdo, extensão e tempo para facilitar a abordagem de problemas em aberto e de decisões pendentes.

O plano de gerenciamento do projeto pode ser sumarizado ou detalhado e pode ser constituído por um ou mais planos auxiliares e outros componentes. Cada um dos planos auxiliares e componentes é detalhado até o nível necessário para o projeto específico. Esses planos auxiliares incluem, mas não se limitam a:

1. Plano de gerenciamento do escopo do projeto
2. Plano de gerenciamento do tempo e/ou cronograma
3. Plano de gerenciamento de custos e/ou planilha de custos
4. Plano de gerenciamento da qualidade
5. Plano de melhorias no processo
6. Plano de gerenciamento de pessoal e/ou recursos humanos
7. Plano de gerenciamento das comunicações
8. Plano de gerenciamento de riscos
9. Plano de gerenciamento de aquisições e/ou procurement

Declaração de Escopo Inicial do Projeto

Outro processo importante que deve ser executado na fase de Inicialização, na área de conhecimento de Integração, é o Desenvolvimento da Declaração do Escopo do Projeto . Os principais documentos a serem utilizados, como suporte, serão o Project Charter, o SOW, além dos fatores ambientais da empresa e os ativos organizacionais, já citados anteriormente. Devem ser seguidas metodologias de gerenciamento de projetos para que o mesmo fique estruturado, possa ser medido e otimizados. Como metodologias cito CMMI, ISO e etc. É interessante que se use um sistema de informações de gerenciamento de projetos com ferramentas como MS-Project, Rational Clearcase, Rational Clearquest, templates, etc. Deve se utilizar também do Export Judgment, que seria o capital intelectual da empresa, como analistas que conheçam os sistemas, engenheiros e arquitetos de software, DBAs, etc.

A declaração do escopo do projeto é a definição do projeto—o que precisa ser
realizado. O processo aborda e documenta as características e limites do projeto e seus produtos e serviços associados, além dos métodos de aceitação e controle do escopo. Uma declaração do escopo do projeto inclui:

• Objetivos do produto e do projeto
• Características e requisitos do produto ou serviço
• Critérios de aceitação do produto
• Limites/fronteiras do projeto
• Entregas e requisitos do projeto
• Restrições do projeto
• Premissas do projeto
• Estrutura organizacional inicial do projeto
• Riscos iniciais definidos
• Milestones iniciais do cronograma
• WBS inicial
• Estimativa aproximada de custos
• Requisitos de gerenciamento de configuração do projeto
• Requisitos Aprovados.

Desenvolvendo um Project Charter

Na área de conhecimento de Integração, na fase de Inicialização, o primeiro processo definido é o de Desenvolvimento do Project Charter. O Project Charter é o documento que formalmente autoriza o projeto. Ele é usualmente assinado pelo Sponsor e autoriza o Gerente de Projetos a usar os recursos nas atividades pertinentes ao projeto.











O Project Charter não é um plano detalhado para o projeto porém ele disponibiliza, para os os envolvidos responsáveis por decisões chaves, informação suficiente para suporta-los nas mesmas.
Os principais elementos para elaboração do Project Chart são:

• Contrato, que pode ser um acordo interno de setores da mesma empresa, via e-mail ou documento próprio da organização; ou ainda um contrato formal caso sejam entre empresas;
• Statement of Work (SOW) ou declaração do trabalho, que é uma narrativa de produtos ou serviços que serão produtos finais do projeto. Nele estão contidos as necessidades de negócio, uma descrição inicial do escopo do produto. Durante o desenvolvimento este escopo será detalhado. Para projetos que envolvem terceiros devem vir juntos com a proposta de trabalho ou como parte do contrato. Deve conter também as premissão e as restrições do projeto, os stakeholders principais e seus papéis no projeto, os riscos do projeto já identificados antecipadamente;
• Fatores Ambientais da Corporação;
• Ativos de Processos Organizacionais.

Fatores ambientais da empresa:

Durante o desenvolvimento do termo de abertura do projeto, devem ser considerados todos e quaisquer sistemas e fatores ambientais da empresa que cercam e influenciam o sucesso do projeto. Isso inclui, mas não se limita a itens como:

• Cultura e estrutura organizacional ou da empresa;
• Normas governamentais ou do setor (por exemplo, regulamentos de agências reguladoras, normas de produtos, padrões de qualidade e padrões de mão-de-obra);
• Infra-estrutura (por exemplo, equipamentos e instalações existentes);
• Recursos humanos existentes (por exemplo, habilidades, disciplinas e conhecimento, como projeto, desenvolvimento, departamento jurídico, contratação e compras);
• Administração de pessoal (por exemplo, diretrizes de contratação e demissão, análises de desempenho dos funcionários e registros de treinamento);
• Sistema de autorização do trabalho da empresa;
• Condições do mercado;
• Tolerância a risco das partes interessadas;
• Bancos de dados comerciais (por exemplo, dados padronizados de estimativa de custos, informações sobre estudos de risco do setor e bancos de dados de riscos);
• Sistemas de informações do gerenciamento de projetos (por exemplo, um conjunto de ferramentas automatizadas, como uma ferramenta de software para elaboração de cronogramas, um sistema de gerenciamento de configuração, um sistema de coleta e distribuição de informações ou interfaces Web para outros sistemas on-line automatizados).

Ativos de processos organizacionais:

Durante o desenvolvimento do termo de abertura do projeto e da documentação subseqüente do projeto, todos e quaisquer ativos usados para influenciar o sucesso do projeto podem ser obtidos a partir dos ativos de processos organizacionais. Todas e quaisquer organizações envolvidas no projeto podem ter políticas, procedimentos, planos e diretrizes formais e informais cujos efeitos devem ser considerados. Processos e procedimentos da organização para realizar o trabalho:

• Processos organizacionais padrão, como normas, políticas (por exemplo, política de segurança e saúde e política de gerenciamento de projetos), ciclos de vida padrão do produto e do projeto, e políticas e procedimentos de qualidade (por exemplo, auditorias de processo, metas de melhoria, listas de verificação e definições padronizadas de processos para uso na organização);
• Modelos (por exemplo, modelos de risco, modelos da estrutura analítica do projeto e modelos do diagrama de rede do cronograma do projeto);
• Diretrizes e critérios para adequação do conjunto de processos padrão da organização para satisfazer às necessidades específicas do projeto;
• Requisitos de comunicação da organização (por exemplo, a tecnologia de comunicação específica disponível, meios de comunicação permitidos, retenção de registros e requisitos de segurança);
• Requisitos ou diretrizes para encerramento do projeto (por exemplo, auditorias finais do projeto, avaliações do projeto, validações de produtos e critérios de aceitação);
• Procedimentos de controles financeiros (por exemplo, relatórios de horas, revisões de despesas e desembolsos necessários, códigos de contabilidade e cláusulas contratuais padrão);

Segue um template que pode ser usado como padrão:

http://docs.google.com/Doc?id=dgj7dpm8_5g796hhcs

Definindo o Sucesso do Projeto

Um projeto completo e de sucesso deve atingir essencialmente os seguintes objetivos:

• dentro do tempo previsto;
• dentro do custo previsto;
• dentro do escopo previsto;
• com qualidade;
• com riscos controlados; e
• recursos bem coordenados.

Gerenciamento de Integração

Uma das áreas de conhecimento mais importantes do projeto é a área de integração. A integração inclue os processos e atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos a atividades de gerenciamento de projetos. A integração pressupõe que vários elementos de um projeto estão corretamente coordenados, é importante percebermos desde o início que tudo que será trabalhado em um projeto deve estar integrado e relacionado com outros aspectos do mesmo. Não devemos trabalhar os plano e etapas do projeto de forma isolada.
Vamos colocar alguns exemplos, uma mudança de escopo estará quase sempre afetando o custo e o cronograma do mesmo, porém pode ou não afetar a qualidade do produto. Uma exigência de uma data específica para entrega do produto final, antecipando o cronograma afetará o mesmo com a redução da duração, porém não obrigatoriamente o esforço ou o custo. Este fato pode também prejudicar a qualidade caso seja necessário reduzir etapas de controle da mesma.
Enfim uma integração entre todas as gerências do projeto são importantes para o sucesso do mesmo.

Progressive Elaboration

Um técnica importante e que as vezes parece óbvia é a Progressive Elaboration ou Rolling Wave Planning. Esta técnica constitui do contínuo aprimoramento e detalhamento do plano de projeto com informações cada vez mais precisas e estimativas mais acuradas enquanto o projeto vai evoluindo durante o tempo. Nesta técnica iniciamos com o plano do projeto ainda incompleto e talvez não tão preciso, porém enquanto o mesmo vai sendo detalhado, vamos atualizando seus planos e tornando-os mais completos. É muito importante iniciar o quanto antes o plano de projeto e manter os seus documentos "vivos", isto é, sempre atualizados e corretos durante o ciclo de vida do projeto.

Mapa com Grupos Principais X Áreas de Conhecimento

Quadro com as 4 principais grupos de processos, 9 áreas de conhecimento de processos e os 44 processos de gerenciamento de projetos segundo o PMI. Clicar na figura acima para obter com maior clareza a sua visualização.

Áreas de Conhecimento de Gerenciamento de Projetos

As nove áreas de gerenciamento de projetos são as seguintes:

1. Integração
2. Escopo
3. Tempo
4. Custo
5. Qualidade
6. Recursos Humanos
7. Comunicação
8. Risco
9. Procurement

Dentro destas áreas temos 44 processos divididos em cinco grandes grupos de processos, como descrito no PMBOK Guide - Third Edition, na qual me baseio para este blog.

Seguem algumas definições importantes:

• Projeto - um esforço temporário para criar um único produto, serviço ou resultado. Temporário não significa necessariamente curto em duração, muitos projetos duram vários anos.
• Programa - um grupo de projetos relacionados de uma forma coordenada para obter benefícios e controle indisponíveis se gerenciados individualmente.
• Gerenciamento de Projetos - a aplicação de conhecimento, skills, ferramentas e técnicas de atividades de projetos para cumprir requerimentos de projetos. Gerenciar projetos inclui identificar requerimentos, estabelecer objetivos claros e atingíveis, balancear demandas concorrentes com escopo bem definido, além de tempo e custo controlados.
• Ciclo de vida de um projeto - um conjunto de fases de projeto sequenciais, cujos nomes e números são determinados pelas necessidades de controle da organização ou organizações involvidas no projeto. São definidos: qual trabalho técnico deverá ser feito em cada fase, quando os deliverables deverão ser gerados, quem será envolvido em cada fase e como será controlado e aprovada cada fase do projeto.
• Sponsor ou Patrocinador - é a pessoa ou grupo de pessoas que irá prover os recursos financeiros para o projeto.

Target Audience

Iniciamos o blog repassando para vocês quem seriam os profissionais que seriam o alvo da audiência deste site:
Gerente de projetos, Gerentes de TI, Analistas de Sistemas, Programadores, Inspetores de Peer Review, Analistas de Testes, Time de Qualidade, Líderes/Coordenadores de Projeto, Stakeholders e todos os outros envolvidos em gerenciamento de projetos de software.