<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>

<channel>
	<title>Stakeholder - Blog sobre Gerenciamento de Projetos</title>
	<atom:link href="http://www.ogerente.com/stakeholder/feed/" rel="self" type="application/rss+xml" />
	<link>http://ogerente.com/stakeholder</link>
	<description>Blog de Gerenciamento de Projetos</description>
	<pubDate>Tue, 18 Nov 2008 20:30:55 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.1</generator>
	<language>en</language>
			<item>
		<title>Mais Gerenciamento de Projetos no Dilbert</title>
		<link>http://ogerente.com/stakeholder/2008/11/18/mais-gerenciamento-de-projetos-no-dilbert/</link>
		<comments>http://ogerente.com/stakeholder/2008/11/18/mais-gerenciamento-de-projetos-no-dilbert/#comments</comments>
		<pubDate>Tue, 18 Nov 2008 20:30:55 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Humor]]></category>

		<category><![CDATA[dilbert]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=254</guid>
		<description><![CDATA[

Mais um pouco sobre Gerenciamento de Projetos no Dilbert:

Agora, esta é excelente:

]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong></strong></em></p>
<p>Mais um pouco sobre Gerenciamento de Projetos no Dilbert:</p>
<p><a title="Dilbert.com" href="http://dilbert.com/strips/comic/2008-11-04/"><img style="border: 0pt none;" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/30000/0000/200/30222/30222.strip.gif" border="0" alt="Dilbert.com" width="512" height="159" /></a></p>
<p>Agora, esta é excelente:</p>
<p><a title="Dilbert.com" href="http://dilbert.com/strips/comic/2008-11-09/"><img style="border: 0pt none;" src="http://dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/30000/0000/200/30227/30227.strip.sunday.gif" border="0" alt="Dilbert.com" width="512" height="230" /></a></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/11/18/mais-gerenciamento-de-projetos-no-dilbert/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Mapa de Milestones</title>
		<link>http://ogerente.com/stakeholder/2008/11/08/mapa-de-milestones/</link>
		<comments>http://ogerente.com/stakeholder/2008/11/08/mapa-de-milestones/#comments</comments>
		<pubDate>Sun, 09 Nov 2008 01:50:06 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Comunicação]]></category>

		<category><![CDATA[Milestones]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=243</guid>
		<description><![CDATA[

Uma ferramenta muito simples, mas bastante prática ajudar na compreensão macro do projeto e de seus principais objetivos é o mapa de milestones.
Este mapa nada mais é do que uma representação gráfica os principais milestones do projeto, sem nenhum detalhamento das atividades.  Por mais que pareça muito simples, gerentes de projetos experientes sabem que não [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong></strong></em></p>
<p>Uma ferramenta muito simples, mas bastante prática ajudar na compreensão macro do projeto e de seus principais objetivos é o mapa de milestones.</p>
<p>Este mapa nada mais é do que uma representação gráfica os principais milestones do projeto, sem nenhum detalhamento das atividades.  Por mais que pareça muito simples, gerentes de projetos experientes sabem que não é raro que conceitos básicos do projeto não estejam claros na mente de diversos stakeholders.</p>
<p>Tomando o exemplo da construção de uma pequeno chalé, este seria um mapa de milestones:</p>
<p><span id="more-243"></span></p>
<p style="text-align: center;"><a href="http://ogerente.com/stakeholder/wp-content/uploads/2008/11/mapa-de-milestones.jpg"><img class="size-full wp-image-248  aligncenter" title="mapa-de-milestones" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/11/mapa-de-milestones.jpg" alt="Mapa de Milestones" width="500" height="175" /></a></p>
<p style="text-align: center;"><em>(Clique para ampliar)</em></p>
<p><strong>Usos Práticos da Ferramenta</strong></p>
<ul>
<li>Compreensão dos objetivos do projeto junto a clientes e outros stakeholders antes de iniciar o planejamento detalhado.</li>
<li>Facilitar sessões de brainstorming, especialmente no inicio do projeto.</li>
<li>Facilitar a comunicação dos principais objetivos até a conclusão do projeto.</li>
<li>Ajuda a manter o foco da equipe no projeto.</li>
<li>Facilitar a comunicação com stakeholders que não querem, não devem ou não precisam conhecer os detalhes do plano de projeto.</li>
<li>Exercício mental para o gerente de projetos e a equipe validarem o plano de projeto</li>
</ul>
<p><strong>Cuidados no Uso da Ferramenta</strong></p>
<ul>
<li>Não misture atividades no mapa.  Não é esse o objetivo da ferramenta.</li>
<li>Resista à tentação de incluir muitas informações no mapa ou exceder no detalhamento.  Isto tirará a atenção dos pontos mais importantes.</li>
<li>Não usar este meio de comunicação com pessoas mais próximas ao dia a dia do projeto.  Estas pessoas querem ver os detalhes do plano de projeto.</li>
<li>Não permitir que, ao apresentar este mapa, se entre em discussões sobre o plano de projeto.  Haverá um momento certo para isto.</li>
</ul>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong></strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/11/08/mapa-de-milestones/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Desenvolvimento Gradual do Escopo</title>
		<link>http://ogerente.com/stakeholder/2008/09/21/desenvolvimento-gradual-do-escopo/</link>
		<comments>http://ogerente.com/stakeholder/2008/09/21/desenvolvimento-gradual-do-escopo/#comments</comments>
		<pubDate>Sun, 21 Sep 2008 21:14:51 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Desenvolvimento de Produtos]]></category>

		<category><![CDATA[Escopo]]></category>

		<category><![CDATA[desenvolvimento]]></category>

		<category><![CDATA[produtos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=234</guid>
		<description><![CDATA[
 
A forma do desenvolvimento do escopo varia muito por tipo de empresa, tipo de projeto, estilo (e autoridade) do gerente de projeto, entre outro fatores.  Por isso, não é fácil definir a melhor ou pior forma de desenvolver o escopo de um projeto.
No entanto, há um tipo de projeto no qual o detalhamento [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p><img class="alignleft size-full wp-image-236" title="footprints" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/09/footprints.jpg" alt="" width="169" height="117" />A forma do desenvolvimento do escopo varia muito por tipo de empresa, tipo de projeto, estilo (e autoridade) do gerente de projeto, <a href="http://ogerente.com/stakeholder/2008/01/23/nivel_detalhamento_projeto_escopo_atividades/" target="_blank">entre outro fatore</a>s.  Por isso, não é fácil definir a melhor ou pior forma de desenvolver o escopo de um projeto.</p>
<p>No entanto, há um tipo de projeto no qual o detalhamento gradual do escopo costuma trazer os melhores resultados: desenvolvimento de novos produtos.</p>
<p>Para deixar claro, por desenvolvimento de novos produtos estou me referindo à criação de algo realmente novo, e cujo projeto passará por fases que ainda não são totalmente conhecidas pelos membros da equipe.   Não entram neste conceito os projetos que envolvem a adaptação de um produto a um novo cliente, por exemplo, já que nestes casos o processo costuma estar muito mais incorporado na empresa.</p>
<p>Posso citar 4 razões pelas quais não vale a pena detalhar o escopo logo no começo do projeto no desenvolvimento de novos produtos :</p>
<p><span id="more-234"></span></p>
<p><strong>1. Evita exageros nos requisitos.</strong> Quando você solicita a alguém que escreva todas suas especificações de uma vez porque será a única oportunidade para fazê-lo, a tendência é que ele inclua tudo que ele pode imaginar e que talvez precise.   Isto, na prática, pode levar à criação de funcionalidades e características desnecessárias para o produto.</p>
<p><strong>2. O escopo não fica completo. </strong> Além de você ter o risco de receber especificações além do realmente necessário, isso não elimina o potencial de escopo incompleto.   Especialmente quando estamos falando em desenvolver algo novo, não é muito sensato imaginar que a equipe e o cliente conseguirão cobrir todas as especificações desde o início.</p>
<p><strong>3. Aumenta o retrabalho.</strong> Se estamos criando algo realmente novo, certamente existirão pontos desconhecidos ao longo do projeto.  Se forçamos a equipe a pensar nos mínimos detalhes antes das primeiras fases do produto estarem prontas, é natural que seja necessário retrabalhar estes detalhes mais adiante.</p>
<p><strong>4. Cria-se uma expectativa pouco realista. </strong> Quando teoricamente temos o escopo detalhado desde o começo, automáticamente os <a href="http://ogerente.com/stakeholder/2007/02/23/o-que-e-um-stakeholder/" target="_blank">stakeholders</a> criarão uma expectativa sobre a consistência daquele escopo e do cronograma consequente.  No momento em que os passos desconhecidos no desenvolvimento de produto causarem mudanças em escopo, custo e prazo, nem todos entenderão isto como algo natural do tipo de projeto sendo executado.</p>
<p>Ditas as razões pela qual desenvolver o escopo gradualmente, cabe ao gerente de projeto determinar exatamente o nível de escopo que é desejado em cada fase.   Não se trata de pensar somente no curto prazo e esquecer do que virá mais adiante&#8230; isto seria um tiro no pé.   O importante é que o escopo das fases mais avançadas seja definido de forma mais macro, e que permita pelo menos:</p>
<ul>
<li>Orientar adequandamente as atividades e deliverables nas fases iniciais.</li>
<li>Estimar o custo e prazo totais do projeto.</li>
<li>Identificar riscos de grande probabilidade ou impacto que devam ser discutidos desde o começo.</li>
<li>Mostrar a viabilidade do projeto (será que não existe uma especificação desejada pelo cliente e que poderá travar o desenvolvimento)?</li>
</ul>
<p>O que costumo dizer é que nunca existem regras fixas, mas sempre deve existir o bom senso.   Nenhum projeto é idêntico ao outro, e o gerente do projeto com a equipe devem buscar os melhores caminhos para seu sucesso.</p>
<p><em>Aproveite para ler <a href="http://ogerente.com/stakeholder/category/escopo/" target="_blank">os outros artigos relativos a escopo</a> no blog.</em></p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/09/21/desenvolvimento-gradual-do-escopo/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Processos de Gerenciamento de Portifólio de Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/09/08/processos-de-gerenciamento-de-portifolio-de-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/09/08/processos-de-gerenciamento-de-portifolio-de-projetos/#comments</comments>
		<pubDate>Mon, 08 Sep 2008 15:32:19 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Portifólio]]></category>

		<category><![CDATA[gerenciamento]]></category>

		<category><![CDATA[processos]]></category>

		<category><![CDATA[projetos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=222</guid>
		<description><![CDATA[
 
O Gerenciamento de Portifólio de Projetos de uma organização envolve o uso de técnicas, processos e ferramentas para que seu conjunto de projetos sejam priorizados adequadamente, aproveitem da melhor forma os recursos disponíveis, e gerem os melhores resultados para os stakeholders.
O Peter Mello, da X.25 Treinamento e Consultoria, montou um fluxograma online que ilustra [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p style="text-align: left;">O Gerenciamento de Portifólio de Projetos de uma organização envolve o uso de técnicas, processos e ferramentas para que seu conjunto de projetos sejam priorizados adequadamente, aproveitem da melhor forma os recursos disponíveis, e gerem os melhores resultados para os <a href="http://ogerente.com/stakeholder/2007/02/23/o-que-e-um-stakeholder/" target="_blank">stakeholders</a>.</p>
<p style="text-align: left;">O <a href="www.vanessamazzafurquim.com" target="_blank">Peter Mello</a>, da <a title="X.25 Treinamento e Consultoria" href="http://www.x25.com.br" target="_blank">X.25 Treinamento e Consultoria</a>, montou um fluxograma online que ilustra os processos recomendados pelo Project Management Institute.</p>
<p style="text-align: left;">Clique <a href="http://www.correntecritica.com/atualizador/igpp/dados/extras/portfolio/" target="_blank">aqui</a> ou na imagem a seguir para ver o fluxograma.</p>
<p style="text-align: center;">
<p style="text-align: center;"><a href="http://www.correntecritica.com/atualizador/igpp/dados/extras/portfolio/" target="_blank"><img class="size-full wp-image-227 alignnone" title="processos-gerenciamento-portifolio-projetos" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/09/processos-gerenciamento-portifolio1.jpg" alt="" width="363" height="271" /></a></p>
<p style="text-align: center;">
<p><em><strong> </strong></em><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/09/08/processos-de-gerenciamento-de-portifolio-de-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Leis da Gerência de Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/09/02/leis-da-gerencia-de-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/09/02/leis-da-gerencia-de-projetos/#comments</comments>
		<pubDate>Tue, 02 Sep 2008 13:40:07 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Humor]]></category>

		<category><![CDATA[projetos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=213</guid>
		<description><![CDATA[
Para relaxar um pouco, segue uma lista bem-humorada de leis da Gerência de Projetos.  Esta lista foi enviada por um participante da lista E-plan.
 

&#8220;Se alguma coisa pode dar errado, vai dar errado.&#8221;
- Lei de Murphy.
&#8220;Se alguma coisa é impossivel dar errado, mesmo assim vai dar errado.&#8221;
- Corolário de O&#8217;Malley à Lei de Murphy.
&#8220;Se [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
Para relaxar um pouco, segue uma lista bem-humorada de leis da Gerência de Projetos.  Esta lista foi enviada por um participante da lista <a href="http://br.groups.yahoo.com/group/planejamento/" target="_blank">E-plan</a>.<br />
<em><strong> </strong></em><br />
<span id="more-213"></span></p>
<p>&#8220;Se alguma coisa pode dar errado, vai dar errado.&#8221;<br />
<strong><em>- Lei de Murphy.</em></strong></p>
<p>&#8220;Se alguma coisa é impossivel dar errado, mesmo assim vai dar errado.&#8221;<br />
<strong><em>- Corolário de O&#8217;Malley à Lei de Murphy.</em></strong></p>
<p>&#8220;Se alguma coisa pode dar errado, vai dar errado da pior maneira possível.&#8221;<br />
<strong><em>- Lei de Sod.</em></strong></p>
<p>&#8220;O volume de trabalho a ser feito sempre se expande de forma a ocupar todo o tempo disponível à sua conclusão.&#8221;<br />
<strong><em>- Lei de Parkinson.</em></strong></p>
<p>&#8220;Se houver 50% de chance de alguma coisa dar errado, dará errado em 90% dos casos.&#8221;<br />
<em><strong> - Lei de Cole.</strong></em></p>
<p>&#8220;Um projeto de dois anos levará três anos. Um projeto de três anos nunca será concluído.&#8221;<br />
<em><strong> - Lei de Smith.</strong></em></p>
<p><em>Murphy, O&#8217;Malley, Sod, Parkinson, Cole e Smith estão vivos e com saúde - trabalhando em seu projeto.</em></p>
<p><em><strong>Alerta de Maquiavel aos Gerentes de Projeto</strong></em><br />
&#8220;Lembre-se que não existe nada mais difícil de fazer, mais perigosa de administrar, ou mais incerto em seu sucesso, que tomar a iniciativa na introdução de uma nova ordem de coisas. Porque o inovador tem como inimigos todos os que se deram bem debaixo das velhas condições, e defensores tépidos naqueles que podem se dar bem debaixo das novas.&#8221;</p>
<p><em><strong>Lei de Woehlke</strong></em><br />
Nada será feito enquanto nada for feito. Os gerentes de projeto não conseguirão o pessoal de que precisam a menos que eles estejam sobrecarregados com horas extras, úlceras e esforços sobrehumanos. Só quando prazos são estourados é que a direção aprova o pessoal que, se estivesse disponível no início, teria permitido cumprir os prazos.</p>
<p><em><strong>Lei de Cohn</strong></em><br />
Quanto mais tempo você gasta reportando o que você está fazendo, menos tempo você tem que fazer qualquer coisa. A estabilidade é alcançada quando você gastar todo seu tempo fazendo nada além de reportar o que você está fazendo.</p>
<p><em><strong>As 7 Fases de um Projeto</strong></em><br />
1. Entusiasmo<br />
2. Desilusão<br />
3. Confusão<br />
4. Pânico<br />
5. Caçada aos culpados<br />
6. Punição dos inocentes<br />
7. Promoção dos não participantes</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/09/02/leis-da-gerencia-de-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Principais Causas de Cancelamento de Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/08/28/principais-causas-de-cancelamento-de-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/08/28/principais-causas-de-cancelamento-de-projetos/#comments</comments>
		<pubDate>Thu, 28 Aug 2008 14:04:30 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Risco]]></category>

		<category><![CDATA[fracasso]]></category>

		<category><![CDATA[projetos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=73</guid>
		<description><![CDATA[
 
A Baseline Magazine publicou o resultado de uma pesquisa feita nos Estados Unidos com o objetivo de levantar as causas pelas quais um projeto &#8220;morre&#8221;.  Apesar da pesquisa ter sido realizada no exterior, e feita principalmente com profissionais de TI, acredito que é uma boa referência para qualquer projeto em qualquer segmento.  Os resultados [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p><img class="alignleft size-full wp-image-74" title="bomba_atomica" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/bomba_atomica.jpg" alt="" width="93" height="105" />A <a title="Baseline Magazine" href="http://www.baselinemag.com/" target="_blank">Baseline Magazine</a> publicou o resultado de uma pesquisa feita nos Estados Unidos com o objetivo de levantar as causas pelas quais um projeto &#8220;morre&#8221;.  Apesar da pesquisa ter sido realizada no exterior, e feita principalmente com profissionais de TI, acredito que é uma boa referência para qualquer projeto em qualquer segmento.  Os resultados foram:</p>
<blockquote><p><strong>30% </strong> por mudanças nas necessidades do negócio</p>
<p><strong>23%</strong> porque o projeto não entregou o que era prometido</p>
<p><strong>14% </strong> porque o projeto deixou de ser uma prioridade</p>
<p><strong>13% </strong> devido a estouro do orçamento</p>
<p><strong>7%</strong> porque não suportava a estratégia de negócios</p>
<p><strong>4%</strong> por atrasos excessivos</p></blockquote>
<p>O gerenciamento do risco deve levar em conta os diversos fatores que podem ter impactos positivos ou negativos no projeto, e esta pesquisa pode ajudar o gerente de projetos a ter em mente temas importantes durante a análise.</p>
<p>Um aspecto que achei interessante da pesquisa é que somente 40% das causas eram relativas a áreas de conhecimento &#8220;núcleo&#8221; de gerenciamento de projetos (2o item:  gerenciamento de escopo,   4o item:  gerenciamento de custos,  6o item:  gerenciamento de tempo).   Os demais 3 itens (1o, 3o e 5o) representam 51% do total e são relativos ao negócio em si.</p>
<p>Isto deve servir de alerta para o gerente de projetos.   Aqueles que ficam excessivamente focados no que acontece DENTRO do projeto podem deixar escapar fatores EXTERNOS que podem vir a influenciar significativamente o projeto.   Ter uma visão destes fatores externos (necessidade do negócio, prioridades da empresa e estratégia institucional) é uma capabilidade essencial para que se possa influenciar os acontecimentos e ajustar os rumos do projeto para que este sobreviva.</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/08/28/principais-causas-de-cancelamento-de-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Problemas no Escopo do Projeto</title>
		<link>http://ogerente.com/stakeholder/2008/07/21/problemas-no-escopo-do-projeto/</link>
		<comments>http://ogerente.com/stakeholder/2008/07/21/problemas-no-escopo-do-projeto/#comments</comments>
		<pubDate>Mon, 21 Jul 2008 19:04:35 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Escopo]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=70</guid>
		<description><![CDATA[
  GA_googleFillSlot("Stakeholder_Post_Sup");

Recentemente um leitor do blog me enviou um e-mail perguntando sobre as consequências de um escopo mal definido no projeto.
Em minha visão, o escopo é simplesmente o aspecto mais crítico de um projeto.   Erros no escopo se espalham automaticamente por todos os outros aspectos do projeto.  A falta de atenção em sua definição [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript">
  GA_googleFillSlot("Stakeholder_Post_Sup");
</script><br />
Recentemente um leitor do blog me enviou um e-mail perguntando sobre as consequências de um escopo mal definido no projeto.</p>
<p>Em minha visão, o escopo é simplesmente o aspecto mais crítico de um projeto.   Erros no escopo se espalham automaticamente por todos os outros aspectos do projeto.  A falta de atenção em sua definição pode trazer conseqüências bastante desagradáveis em termos de custos, prazos, comunicação e riscos.</p>
<p>Estive pensando em como um escopo poderia estar “defeituoso”, e cheguei a quatro aspectos que devem ser avaliados pelos Gerentes de Projeto para evitar dores de cabeça:</p>
<p><span id="more-70"></span></p>
<p><strong>Escopo Incompleto</strong></p>
<p>Ocorre quando, na decomposição do(s) produto(s) princial(is) do projeto, os sub-produtos não são identificados adequadamente.   A equipe de projeto deve se perguntar “os sub-produtos de um produto são todos os componentes necessários para sua composição?”.</p>
<p>O Gerente de Projeto, mesmo que não tenha conhecimento técnico do que está sendo produzido, deve usar o bom senso e questionar repetidas vezes a composição do escopo.</p>
<p><strong>Detalhamento Insuficiente</strong></p>
<p>Muitas vezes o escopo está completo, mas os produtos não estão divididos em subprodutos que permitam uma correta definição de tarefas, tempos, custos, etc.   Um exemplo grosseiro seria o escopo de uma residência sendo definido pelos sub-produtos “Casa” e “Quintal”.  Apensar dos sub-produtos descreverem o produto final do projeto, eles mesmos precisam de maior detalhamento para que o projeto possa ser executado adequadamente.</p>
<p><strong>Confusão entre Tarefas e Produtos</strong></p>
<p>Também é um erro comum confundir tarefas com produtos.  As tarefas são atividades interdependentes que levam à conclusão de um produto ou sub-produto.    Este tipo de confusão, pode levar à mesma situação de escopo incompleto.   A classificação de tarefas como produtos é muito mais do que uma questão de nomenclatura, é um sinal da falta de uma verdadeira compreensão do escopo do projeto.</p>
<p><strong>Falta de Clareza</strong></p>
<p>Um grande erro é deixar de lado o dicionário da Estrutura Analítica do Projeto, assumindo que o escopo está claro para todos somente porque está completo.   Esta é uma armadilha tradicional dos projetos, que pode ser facilmente evidenciada pelo Gerente&#8230; basta que ele pergunte a pessoas de perfis diferentes sua compreensão dos diversos produtos definidos no escopo.  Se a descrição do produto não foi clara, certamente ele receberá respostas bastante diversificadas.</p>
<p>Para finalizar, é importante esclarecer que escopo incompleto não é um problema impeditivo no projeto.  Na realidade, em grande parte dos projetos é o que será encontrado pelo Gerente.  O mais importante é que as lacunas estejam claras para que o escopo seja melhorado com o avanço do projeto, e o risco inerente a um escopo incompleto seja bem gerenciado.</p>
<p><script type="text/javascript">
  GA_googleFillSlot("Stakeholder_Post_Inf");
</script><br />
<!-- END OF TAG FOR SLOT Stakeholder_Post_Inf<br />
     --></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/07/21/problemas-no-escopo-do-projeto/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Entrando no Meio do Projeto – As Soluções</title>
		<link>http://ogerente.com/stakeholder/2008/06/12/entrando-no-meio-do-projeto-solucoes/</link>
		<comments>http://ogerente.com/stakeholder/2008/06/12/entrando-no-meio-do-projeto-solucoes/#comments</comments>
		<pubDate>Thu, 12 Jun 2008 12:26:17 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Gerente de Projetos]]></category>

		<category><![CDATA[Mudanças]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=146</guid>
		<description><![CDATA[
 
No último texto, falei sobre algumas das dificuldades que os Gerentes de Projeto podem enfrentar ao entrar em um projeto depois de seu início. Neste texto (sim, está um pouco atrasado…), vou dar algumas idéias sobre como contornar estas situações:

Projeto em Geral: 

Inicie um processo de documentação do projeto e recuperação da informação passada. [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em><br />
No último texto, falei sobre algumas das dificuldades que os Gerentes de Projeto podem enfrentar ao entrar em um projeto depois de seu início. Neste texto (sim, está um pouco atrasado…), vou dar algumas idéias sobre como contornar estas situações:</p>
<p><span id="more-146"></span><br />
<strong>Projeto em Geral: </strong></p>
<ul>
<li>Inicie um processo de documentação do projeto e recuperação da informação passada. Só tome cuidado para não tornar isso a prioridade máxima, ou vão confundi-lo com um burocrata. Tome passos incrementais e vá mostrando os benefícios.</li>
<li>Organize-se. Como ninguém vai gostar de passar muito tempo explicando os detalhes para o novo Gerente de Projetos, tente buscar o máximo que puder sozinho, e aproveite bem o tempo com a equipe preparando perguntas e questões antecipadamente.</li>
</ul>
<p><strong>Equipe:</strong></p>
<ul>
<li>Para criar um ambiente positivo com a equipe, o Gerente deve saber ser duro nos momentos certos (por exemplo, com quem faz corpo mole de forma proposital), e compreender as necessidades de cada um. A confiança não será estabelecida da noite para o dia, e respeito, honestidade e competência farão com que a equipe “adote” o novo Gerente como um líder autêntico.</li>
<li>Sugiro também uma reunião de kick-off, não para falar do projeto, mas da forma de trabalho da equipe. Neste reunião, o Gerente deve assumir compromissos que reforcem o que citei no item anterior, e pedir o mesmo do grupo.</li>
</ul>
<p><strong>Escopo:</strong></p>
<ul>
<li>Em minha opinião, é o primeiro problema que o GP deve corrigir. Um escopo mal definido afeta todos os outros aspectos do projeto.</li>
<li>É comum que uma equipe inexperiente em Gerenciamento de Projetos ache que todo o trabalho está bem definido, mas basta uma reunião de detalhamento de escopo para achar lacunas e divergências críticas.</li>
</ul>
<p><strong>Cliente:</strong></p>
<ul>
<li>O cliente deve saber imediatamente que o Gerente será um dos principais pontos de contato a partir daquele momento.</li>
<li>Para ganhar a confiança do cliente rapidamente, identifique alguns de seus pontos de insatisfação, e marque uma primeira reunião de apresentação mostrando que está ciente das oportunidades de melhoria e de como você irá agir. Mais importante: cumpra rigorosamente este compromisso, e você alcançará rapidamente a credibilidade desejada.</li>
</ul>
<p><strong>Autoridade e Reconhecimento Formal:</strong></p>
<ul>
<li>Lidar com a equipe pode ser mais fácil do que lidar com outros stakeholders externos que não reconhecem sua autoridade no projeto.</li>
<li>O líder da empresa deve formalizar sua posição no projeto. Isto pode até ser feito com um simples e-mail, mas o apoio à sua atuação deve ficar explícita.</li>
<li>Cabe ao Gerente tomar ações rápidas quando identificar que outros stakeholders estão atrapalhando seu trabalho como líder do projeto, para que não fiquem dúvidas em relação a seu compromisso com o sucesso do mesmo.</li>
</ul>
<p><strong>Recursos: </strong></p>
<ul>
<li>A menos que tudo esteja perfeitamente bem documentando, refaça a previsão de recursos necessários para o projeto. Você será cobrado pelos resultados, então não deixe de ter certeza da confiabilidade dos números.</li>
<li>Caso identifique que os recursos são insuficientes, comunique isso imediatamente ao patrocinador do projeto (mesmo que não consiga mais recursos). Adiar esta informação somente o tornará cúmplice das estimativas iniciais.</li>
</ul>
<p><strong>Processos: </strong></p>
<ul>
<li>Gradualmente e pacientemente, implemente boas práticas de gerenciamento de projetos. Como citei no começo, quem não entende do assunto, ou tem a cabeça fechada, achará que você está querendo burocratizar o projeto</li>
<li>Ao invés de colocar processos “na marra”, explique e mostre na prática os benefícios que serão obtidos quando a empresa gerencia bem seus projetos.</li>
</ul>
<p>Uma dica final… não desanime nem desista. Se todos já soubessem gerenciar bem os projetos, ninguém precisaria de você.<br />
<script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/06/12/entrando-no-meio-do-projeto-solucoes/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Entrando no Meio do Projeto – As Dificuldades</title>
		<link>http://ogerente.com/stakeholder/2008/05/16/entrando-no-meio-do-projeto-%e2%80%93-as-dificuldades/</link>
		<comments>http://ogerente.com/stakeholder/2008/05/16/entrando-no-meio-do-projeto-%e2%80%93-as-dificuldades/#comments</comments>
		<pubDate>Fri, 16 May 2008 12:22:22 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Gerente de Projetos]]></category>

		<category><![CDATA[Mudanças]]></category>

		<category><![CDATA[dificuldades]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=142</guid>
		<description><![CDATA[
 
Todos sabemos que não são muitas as organizações que começam um projeto pelo gerente de projetos. Em muitos casos, o gerente é designado depois que algumas atividades já começaram. Em outros, piores ainda, a organização do projeto somente é considerada quando os chefes percebem que a coisa está “um pouco bagunçada”.
Para o Gerente de [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em><br />
Todos sabemos que não são muitas as organizações que começam um projeto pelo gerente de projetos. Em muitos casos, o gerente é designado depois que algumas atividades já começaram. Em outros, piores ainda, a organização do projeto somente é considerada quando os chefes percebem que a coisa está “um pouco bagunçada”.</p>
<p>Para o Gerente de Projetos, isto pode ser um verdadeiro desafio. Como o assunto é extenso, resolvi escrever dois textos sobre o tema, um descrevendo as dificuldades e outro sugerindo algumas ações para contornar os obstáculos.</p>
<p>Então vamos às dificuldades:<br />
<span id="more-142"></span><strong></strong></p>
<p><strong>Projeto em Geral: </strong>provavelmente não existirá muita documentação organizada… mais provável ainda é que ninguém estará disposto a passar muitas horas explicando todos os detalhes do que já ocorreu para o novo Gerente de Projeto. Nem sempre é fácil tirar este atraso, especialmente quando a informação simplesmente não está disponível.</p>
<p><strong>Equipe: </strong>mesmo que o GP seja conhecido na empresa, ele não era parte do grupo inicial de trabalho. Isto pode instantaneamente criar uma resistência por parte da equipe, que não verá o GP como um líder “autêntico”. A tendência é que todos continuem a dar mais atenção a seu chefe funcional do que ao Gerente de Projetos.</p>
<p><strong>Escopo: </strong>em projetos que começaram com pouca organização, um dos aspectos que mais sofre é o escopo. Provavelmente não estará bem definido, e o grande risco é que cada stakeholder tenha uma visão um pouco diferente de qual é realmente o escopo do projeto.</p>
<p><strong>Cliente: </strong>se o cliente não conhece o Gerente de Projeto desde o início, foi perdida a oportunidade de criar um bom relacionamento rapidamente. Além disso, caso a desorganização do projeto já tenha atingido o cliente, o GP entra com saldo negativo.</p>
<p><strong>Autoridade e Reconhecimento Formal:</strong> Se não houve a preocupação em gerenciar o projeto adequadamente desde o começo, não é de duvidar que o Gerente de Projeto será incluído sem uma formalização de sua atividade e autoridade pelos líderes da empresa. Situações assim podem amarrar completamente a atividade do GP e comprometer o desempenho do projeto.</p>
<p><strong>Recursos:</strong> será que alguém já fez uma estimativa aceitável dos recursos necessários para o projeto? Ou estão trabalhando com aquela ordem de grandeza da diretoria? Claro, talvez a estimativa inicial era acima da realidade, mas é para isso que existe a Lei de Murphy… para garantir que você perceba que os recursos estimados são insuficientes.</p>
<p><strong>Processos:</strong> todo projeto deve ter alguns processos, controles e relatórios para aumentar suas chances de sucesso. Depois que a equipe começou a trabalhar sem este rigor, a implementação de processos passa a ser vista como burocracia desnecessária, especialmente se a falta de organização ainda não causou nenhum impacto negativo significativo.</p>
<p>Enfim, estou pintando aqui um cenário bastante pessimista. A situação real de um Gerente de Projeto que caiu de pára-quedas em meio a um novo projeto pode ser bastante diferente. Inclusive, algumas empresas e líderes conseguem fazer esta mudança sem nenhum stress, para felicidade do GP.</p>
<p>Nos próximos dias, escreverei sobre como o GP deve agir nestas situações.<br />
<script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/05/16/entrando-no-meio-do-projeto-%e2%80%93-as-dificuldades/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Projetos e Recursos Humanos</title>
		<link>http://ogerente.com/stakeholder/2008/04/25/projetos-e-recursos-humanos/</link>
		<comments>http://ogerente.com/stakeholder/2008/04/25/projetos-e-recursos-humanos/#comments</comments>
		<pubDate>Fri, 25 Apr 2008 12:07:49 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Recursos Humanos]]></category>

		<category><![CDATA[rh]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/?p=137</guid>
		<description><![CDATA[
 
Tive o prazer de ser entrevistado para uma matéria da revista Melhor Gestão de Pessoas (revista oficial da ABRH), que tratava da participação das áreas de Recursos Humanos em projetos. O contato para a entrevista partiu de minha série de artigos sobre Personagens de Projetos, e inclusive o conteúdo foi resumido em uma página [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em><br />
Tive o prazer de ser entrevistado para uma matéria da revista <a href="http://revistamelhor.uol.com.br/" target="_blank">Melhor Gestão de Pessoas</a> (revista oficial da <a href="http://www.abrhnacional.org.br/" target="_blank">ABRH</a>), que tratava da participação das áreas de Recursos Humanos em projetos. O contato para a entrevista partiu de minha <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">série de artigos sobre Personagens de Projetos</a>, e inclusive o conteúdo foi resumido em uma página completa da revista.</p>
<p>Realmente não são muitas organizações que possuem um departamento de RH realmente ligado à estrutura de projetos. Isto dificulta a vida de todos, já que o Gerente de Projetos tem maior dificuldade em montar uma equipe bem estruturada, enquanto os profissionais de RH acabam ficando sem uma visão clara das necessidades dos projetos.</p>
<p>A matéria traz diversos pontos interessantes para reflexão:</p>
<ul>
<li>Softwares, metodologias e processos são somente ferramentas, mas não são eles que executam o projeto. Um projeto é feito de pessoas, e portanto o RH deve ser uma peça fundamental para seu sucesso.</li>
<li>O RH pode ajudar, e muito, na seleção de equipes. Para isto é importante que se conheçam os detalhes do projeto e os profissionais de RH tenham um treinamento em projetos para que conheçam as competências necessárias.</li>
<li>As práticas de Gerenciamento de Projetos são mais difundidas em áreas técnicas, como TI e Engenharia. Isto não é necessariamente uma dificuldade para os profissionais de RH, e pode ser na realidade um grande diferencial quando eles se capacitam para aplicar seus conhecimentos em Gestão de Pessoas nos projetos.</li>
<li>Um gestor de projetos é um gestor de pessoas (opa… frase minha!).</li>
<li>É muito importante que os novos gerentes de projetos tenham um treinamento específico em RH e que possam também contar com os profissionais de recursos humanos das empresas (ok… também é frase minha).</li>
</ul>
<p>Fiquei muito satisfeito com o fato de uma publicação de Recursos Humanos ter dado atenção ao aspecto humano do Gerenciamento de Projetos. Certamente é um passo muito importante para uma convivência mais produtiva entre os Gestores de Projetos e os Gestores de Capital Humano.<br />
<script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/04/25/projetos-e-recursos-humanos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>A Evolução da Carreira do Gerente de Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/03/24/a-evolucao-da-carreira-do-gerente-de-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/03/24/a-evolucao-da-carreira-do-gerente-de-projetos/#comments</comments>
		<pubDate>Mon, 24 Mar 2008 04:43:54 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Gerente de Projetos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/03/24/a-evolucao-da-carreira-do-gerente-de-projetos/</guid>
		<description><![CDATA[
 
Em muitas funções das empresas, a evolução do profissional segue um caminho relativamente linear.  Os passos para chegar ao topo são de certa forma conhecidos, e muitas vezes até divulgados abertamente pela organização.
Na carreira de gerenciamento de projetos, a situação é um pouco diferente.  Em primeiro lugar, a disciplina e os cargos [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em><br />
Em muitas funções das empresas, a evolução do profissional segue um caminho relativamente linear.  Os passos para chegar ao topo são de certa forma conhecidos, e muitas vezes até divulgados abertamente pela organização.</p>
<p>Na carreira de gerenciamento de projetos, a situação é um pouco diferente.  Em primeiro lugar, a disciplina e os cargos de GP ainda estão nas fases iniciais de adoção por muitas empresas.   Mesmo naquelas com maior maturidade na área, nem sempre há um caminho bem definido.</p>
<p>Isto, no entanto, não deve ser um fator de preocupação para o Gerente de Projetos.  Quando seu trabalho é bem feito, ele adquire um conhecimento ímpar da organização, das pessoas e dos processos.  Este conhecimento é um grande diferencial estratégico que o profissional tem em sua evolução.   Um bom gerente de projeto se torna parte essencial da organização, um elo para que todas as áreas funcionem em harmonia.</p>
<p>Com isto em mente, imaginei os seguintes caminhos na carreira de um Gerente de Projetos:</p>
<p><span id="more-67"></span></p>
<p><strong>Opção 1 – dentro de Gerenciamento de Projetos,  na mesma empresa.</strong></p>
<blockquote><p>Quando a organização tem alta maturidade na área, pode ter uma carreira estruturada, que permite ao profissional iniciar nas equipes de projetos, passar a gerente de projetos, depois evoluindo para a coordenação de projetos maiores, portifólios e programas.  Nestas empresas, o profissional pode crescer até uma posição diretiva, e daí saltar à vice-presidência ou presidência.  Ou seja&#8230; não há limites.</p></blockquote>
<p><strong>Opção 2 – em outras áreas na mesma empresa</strong></p>
<blockquote><p>Mesmo que uma empresa não consiga oferecer ao Gerente de Projetos uma evolução em sua carreira dentro da mesma área, ela pode perceber o valor do conhecimento que o profissional adquiriu em seu trabalho na empresa e oferecer posições de alta responsabilidade em outras áreas.  Isto depende muito do perfil e formação da pessoa, mas é um caminho que também pode oferecer muitas possibilidades quando a ligação entre profissional e empresa é sincera e transparente.</p></blockquote>
<p><strong>Opção 3 – dentro de Gerenciamento de Projetos, em outra empresa.</strong></p>
<blockquote><p>Se o Gerente de Projetos não vê um caminho para seu crescimento na empresa, pode buscar novas oportunidades no mercado, preferencialmente em organizações que possuam uma estrutura mais adequada para projetos (ou tenham a visão de criá-la).</p></blockquote>
<p><strong>Opção  4  – em outras áreas na mesma empresa</strong></p>
<blockquote><p>Com o conhecimento multidisciplinar adquirido, o profissional pode buscar novos caminhos e desafios mesmo fora do Gerenciamento de Projetos.  Estas possibilidades dependem muito da forma como foi desenvolvida a carreira e o aprendizado do gerente.</p></blockquote>
<p><strong>Opção 5 – consultoria!</strong></p>
<blockquote><p>Se o profissional realmente soube tirar o máximo proveito de sua carreira, e tiver espírito empreendedor, pode partir para a atividade de consultoria, na qual os desafios costumam ser ainda maiores e mais complexos.</p></blockquote>
<p>Analisando estas opções, há alguns pontos que empresas e profissionais da área devem ter em mente para fazer o melhor uso do tempo e dinheiro investido:</p>
<p><strong>Empresas: </strong> devem oferecer caminhos de evolução e crescimento para os Gerentes de Projeto, de outra forma correm o risco de perder importante ativo intelectual.  Quando não existe uma carreira estruturada em projetos na empresa, não é suficiente “encaixar” o profissional em qualquer função, somente para não perdê-lo&#8230; além de uma falta de respeito com a pessoa, significa somente adiar sua saída da empresa.</p>
<p><strong>Profissionais da Área:</strong> em primeiro lugar, devem conhecer suas possibilidades dentro da organização, planejar suas opções de carreira e definir ações que o levem na direção desejada.  Segundo, o Gerente de Projetos não deve ficar concentrado unicamente em métodos e controles&#8230; deve participar ativamente do projeto e buscar o conhecimento multidisciplinar que sua função oferece como nenhuma outra.<br />
<script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/03/24/a-evolucao-da-carreira-do-gerente-de-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Quando o Otimismo é um Fator Negativo nos Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/02/25/quando-o-otimismo-e-um-fator-negativo-nos-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/02/25/quando-o-otimismo-e-um-fator-negativo-nos-projetos/#comments</comments>
		<pubDate>Mon, 25 Feb 2008 18:29:31 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Cultura]]></category>

		<category><![CDATA[Equipe]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/02/25/quando-o-otimismo-e-um-fator-negativo-nos-projetos/</guid>
		<description><![CDATA[
 
“O Gerente de Projetos deve limitar o otimismo no projeto”.  Parece estranho dizer isso, não?  Na realidade existe um otimismo bom e um otimismo ruim, o primeiro deve ser incentivado pelo Gerente, o outro combatido arduamente, pois pode ser um fator de alto risco para o fracasso do projeto.
A diferença entre os [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p>“O Gerente de Projetos deve limitar o otimismo no projeto”.  Parece estranho dizer isso, não?  Na realidade existe um otimismo bom e um otimismo ruim, o primeiro deve ser incentivado pelo Gerente, o outro combatido arduamente, pois pode ser um fator de alto risco para o fracasso do projeto.</p>
<p>A diferença entre os dois tipos de otimismo é o seguinte:</p>
<p><span id="more-65"></span></p>
<p><em><strong>Otimismo Bom:</strong></em> é aquele que leva a equipe e outros stakeholders a acreditarem no projeto, buscar a superação nas dificuldades e agir em direção a um bom resultado.  Neste tipo de otimismo, ainda impera o realismo, ou seja, há uma visão clara e transparente da situação do projeto para que as decisões tomadas sejam as mais corretas possíveis.</p>
<p><em><strong>Otimismo Ruim:</strong></em> é aquele que cega o líder e a equipe, e gera expectativas irreais, previsões inalcançáveis e desculpas esfarrapadas.  Além de dificilmente atingir os objetivos, a equipe excessivamente otimista joga a culpa do erro em algum dos fatores que não atingiram os objetivos irreais, e não no planejamento errôneo que foi feito.</p>
<p>Então, que fique bem claro: não estou pregando que o Gerente de Projeto deva ser pessimista.  Muito pelo contrário, ele deve ser um dos mais otimistas no projeto, e deve usar o otimismo como fator de motivação para a equipe.  No entanto, sempre com o pé no chão e garantindo que as decisões, premissas e expectativas possuem uma âncora sólida.</p>
<p>O fato é que, se todas as variáveis são levadas em consideração a partir de uma visão muito otimista, inevitavelmente algumas não atingirão o resultado desejado, e isto impactará em tempo, custos e qualidade.  Em outras palavras, na média alguns resultados ficarão fora do desejado e não haverá margens para recuperar o tempo/dinheiro perdidos.  Novamente, neste caso a culpa foi do planejamento, não do objetivo específico que não foi atingido.</p>
<p>Para detectar e corrigir o excesso de otimismo, a melhor ferramenta para o Gerente de Projeto é o questionamento.   Devem-se buscar com a equipe as fontes de dados e informações que levaram a uma decisão ou previsão.   Se estas fontes não são totalmente sólidas, é necessário avaliar cenários alternativos, com perspectivas diferentes das iniciais.  O Gerente deve descobrir os diferentes caminhos e probabilidades que uma situação pode gerar.</p>
<p>Estas são duas pequenas dicas que com o tempo percebi que ajudam a trazer a realidade de volta às atividades do projeto:</p>
<ol>
<li>Quando alguém da equipe diz “Ah, eu acho que conseguimos”, desconfie instantaneamente.  Não que a capacidade do grupo deva ser questionada, mas é um sinal de que o tema deve ser explorado mais a fundo antes de aceitar uma perspectiva.</li>
<li>Documente as informações.  Quando a previsão ou informação que alguém lhe passa é documentada, a pessoa terá um cuidado especial em mostrar a realidade ao invés de apresentar situações quase impossíveis de alcançar, já que saberá que se o resultado não for atingido, será confrontado com o que disse no começo.</li>
</ol>
<p>Finalmente, lembre-se:  dar expectativas excessivamente otimistas é algo natural de alguns profissionais, já que buscam um conforto momentâneo (dar a informação que o chefe ou outros querem ouvir), com a esperança de não serem questionados no futuro.  Dentro de um projeto, o Gerente de Projeto é a pessoa responsável por eliminar este tipo de cultura e atitude, criando um ambiente de transparência no trabalho em equipe.</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/02/25/quando-o-otimismo-e-um-fator-negativo-nos-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Gerente de Projeto – Líder ou Seguidor?</title>
		<link>http://ogerente.com/stakeholder/2008/02/16/gerente-de-projeto-%e2%80%93-lider-ou-seguidor/</link>
		<comments>http://ogerente.com/stakeholder/2008/02/16/gerente-de-projeto-%e2%80%93-lider-ou-seguidor/#comments</comments>
		<pubDate>Sat, 16 Feb 2008 18:32:52 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Gerente de Projetos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/02/16/gerente-de-projeto-%e2%80%93-lider-ou-seguidor/</guid>
		<description><![CDATA[
 
Muitas empresas adotam processos de Gerenciamento de Projetos, mas a distância entre a forma que o fazem pode ser abismal.  Nestes cenários, o papel do Gerente de Projeto também pode ser incrivelmente diferente.
Podemos ver esta diferença também nos anúncios de emprego.  Não é difícil encontrar  vagas com salários que variam de [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p>Muitas empresas adotam processos de Gerenciamento de Projetos, mas a distância entre a forma que o fazem pode ser abismal.  Nestes cenários, o papel do Gerente de Projeto também pode ser incrivelmente diferente.</p>
<p>Podemos ver esta diferença também nos anúncios de emprego.  Não é difícil encontrar  vagas com salários que variam de R$ 5.000 a mais de R$ 10.000.  Isto nos dá uma idéia de como organizações diferentes enxergam a atividade de gerenciamento de projetos.</p>
<p>Apesar de existirem inúmeras variações, existem dois grandes grupos nos quais podemos encaixar a maioria dos Gerentes de Projeto:</p>
<p><span id="more-64"></span><br />
<strong>Os Líderes</strong></p>
<ul>
<li>São co-responsáveis pelo sucesso do projeto.</li>
<li>Possuem algum grau de autoridade sobre a equipe e as atividades.</li>
<li>Implementam processos de gerenciamento de projetos que são adotados pela organização.</li>
<li>Participam ativamente nas decisões de projeto.</li>
<li>Sua preocupação principal é fazer acontecer.</li>
<li>Costumam ser profissionais com mais experiência na área.</li>
</ul>
<p><strong>Os Seguidores</strong></p>
<ul>
<li>Servem como suporte para os responsáveis pelo projeto.</li>
<li>Colhem informações para organizá-las, sem ter influência direta sobre a execução das atividades.</li>
<li>Implementam poucos processos de gerenciamento de projetos.</li>
<li>Possuem pouca participação nas decisões de projeto.</li>
<li>Sua preocupação principal é assegurar a correta organização dos dados para fornecer boas informações para os responsáveis pelo projeto.</li>
<li>Costumam ser profissionais menos experientes.</li>
</ul>
<p>É claro que o interesse de todo profissional da área é ser um Gerente de Projeto líder.  No entanto, nem sempre as empresas possuem a cultura ou gestores que se encaixem bem com este tipo de atuação.</p>
<p>Ao contratar um Gerente de Projeto, o líder de uma empresa deve ter claro qual papel ele que a organização adote para o profissional, e buscar a pessoa adequada.  Da mesma forma, os profissionais de gerenciamento de projetos devem pesquisar bem a cultura e a forma de trabalho da organização, para garantir que poderá se adaptar bem à realidade do dia-a-dia.<br />
<script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/02/16/gerente-de-projeto-%e2%80%93-lider-ou-seguidor/feed/</wfw:commentRss>
		</item>
		<item>
		<title>A Procrastinação e os Atrasos nos Projetos</title>
		<link>http://ogerente.com/stakeholder/2008/02/02/a-procrastinacao-e-os-atrasos-nos-projetos/</link>
		<comments>http://ogerente.com/stakeholder/2008/02/02/a-procrastinacao-e-os-atrasos-nos-projetos/#comments</comments>
		<pubDate>Sat, 02 Feb 2008 14:43:06 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Atividades]]></category>

		<category><![CDATA[Gerenciamento do Tempo]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/02/02/a-procrastinacao-e-os-atrasos-nos-projetos/</guid>
		<description><![CDATA[
 
A procrastinação é um mal conhecido dos profissionais e das empresas.  No entanto, você já parou para pensar no impacto real que ela tem sobre os projetos?   Estive pensando em situações importantes de atraso em alguns projetos que participei nos últimos anos, e notei que grande parte deles poderia ter sido [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p>A procrastinação é um mal conhecido dos profissionais e das empresas.  No entanto, você já parou para pensar no impacto real que ela tem sobre os projetos?   Estive pensando em situações importantes de atraso em alguns projetos que participei nos últimos anos, e notei que grande parte deles poderia ter sido evitada ou mitigada se a tarefa tivesse começando no momento previsto.</p>
<p>Ao planejar a tarefa de um projeto, normalmente usamos a melhor estimativa possível, que não seja muito otimista nem pessimista.   Muitos gerentes de projeto aplicam ainda uma pequena margem adicional, especialmente se os detalhes da atividade ainda não estão muito claros.  A partir disso, as possibilidades de prazo real de conclusão variam entre um cenário otimista e um pessimista.  Esta tarefa poderia ser representada desta forma:</p>
<p align="center"><span id="more-62"></span></p>
<p><img alt="ProcrastinaÃ§Ã£o e Gerenciamento de Projetos" id="image60" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/02/STAKE%20-%20Procrastina%C3%A7%C3%A3o1.jpg" /></p>
<p>Que efeito a procrastinação tem sobre uma tarefa?   Muitas vezes, o início de uma atividade é adiado simplesmente por falta de vontade e disciplina de seguir o planejamento.  Os responsáveis pelas tarefas (e os Gerentes de Projeto), criam auto-justificativas para que se sintam confortáveis com a decisão, como “se começarmos mais tarde vai dar tempo”.</p>
<p>O problema é que ao procrastinar e começar uma tarefa somente quando parece que não há mais tempo para adiá-la é que a nova previsão otimista passa a ser o que era antes a estimativa mais provável.  Em outras palavras, o mínimo que será conseguido é a média das possibilidades anteriores.  Qualquer outro fator externo que cause variações na execução da tarefa fará com que se consuma a margem de tempo ou até cause atrasos adicionais, como no imagem a seguir:</p>
<div style="text-align: center"><img alt="ProcrastinaÃ§Ã£o e Gerenciamento de Projetos" id="image61" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/02/STAKE%20-%20Procrastina%C3%A7%C3%A3o2.jpg" /></div>
<p>Mais grave ainda é quando a equipe não percebe (ou percebe, mas não quer admitir) que o atraso foi causado pela procrastinação, e jogam a culpa do atraso no fator externo.  Esta situação não é rara, e quando se torna comum pode causar sérios problemas no andamento do projeto.O Gerente de Projeto deve monitorar constantemente a procrastinação em sua equipe.  Sempre que uma tarefa não inicie no momento determinado, deve avaliar as reais causas (e não as desculpas superficiais) e corrigir atitudes.  O próprio Gerente deve se policiar para não cair nas mesmas armadilhas de adiamento das atividades.</p>
<p>Corrigir a procrastinação na equipe não é tarefa fácil.   Se já é complicado acertar sua própria atitude em relação às atividades, imagine então acertar a dos outros.  Minha sugestão é uma combinação de fatores objetivos (como estatísticas sobre os atrasos) e subjetivos (dar o exemplo, motivar a equipe, demonstrar os benefícios do cumprimento dos prazos).</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/02/02/a-procrastinacao-e-os-atrasos-nos-projetos/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Nível de Detalhamento do Projeto</title>
		<link>http://ogerente.com/stakeholder/2008/01/23/nivel_detalhamento_projeto_escopo_atividades/</link>
		<comments>http://ogerente.com/stakeholder/2008/01/23/nivel_detalhamento_projeto_escopo_atividades/#comments</comments>
		<pubDate>Thu, 24 Jan 2008 01:07:39 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Atividades]]></category>

		<category><![CDATA[Escopo]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/01/23/nivel_detalhamento_projeto_escopo_atividades/</guid>
		<description><![CDATA[
 
O nível de detalhamento do escopo e das atividades de um projeto é sempre uma decisão importante para o gerente de projetos.   Um excesso de detalhes pode levar a uma sobrecarga de gerenciamento e até irritação por parte da equipe, enquanto a falta de detalhes pode dificultar o acompanhamento e a identificação [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p>O nível de detalhamento do escopo e das atividades de um projeto é sempre uma decisão importante para o gerente de projetos.   Um excesso de detalhes pode levar a uma sobrecarga de gerenciamento e até irritação por parte da equipe, enquanto a falta de detalhes pode dificultar o acompanhamento e a identificação de riscos e atrasos.</p>
<p>Cada projeto tem seu nível adequado de detalhamento.  Estes são os principais aspectos que devem ser considerados ao definir o nível de detalhamento da EAP e atividades do projeto:</p>
<p><span id="more-58"></span><br />
<strong>Duração do projeto</strong></p>
<p>Em projetos de curta duração, um detalhamento maior pode ser bastante útil, já que normalmente a margem de erro é muito pequena.   Já em projetos longos, o acompanhamento e controle de pequenos passos incrementais em cada atividade e <em>deliverable </em>enlouqueceria o Gerente de Projeto.</p>
<p><strong>Nível de maturidade da equipe</strong></p>
<p>Equipes mais experientes e acostumadas com metodologias de gerenciamento de projetos podem ter atividades mais longas, e o gerente não tem a necessidade de monitorar cada passo tomado.   Quando o time é formado por novatos, a situação é bem diferente, e um detalhamento maior das atividades pode ajudar à equipe e ao gerente na condução do projeto.</p>
<p><strong>Experiência do Gerente de Projeto</strong></p>
<p>Por mais que fatos sejam importantes, o “feeling” também é uma ferramenta importante para o gerente de projeto.  Quando ele tem a experiência necessária, saberá identificar o nível de detalhamento mais adequado a cada situação.   Lembrando somente que agir por intuição não deve substituir uma análise cuidadosa e objetiva da realidade do projeto.</p>
<p><strong>Feedback da equipe</strong></p>
<p>Alguns profissionais se sentem mais à vontade quando não há um controle detalhista de suas atividades, outros gostam do detalhamento porque os ajuda em sua própria organização.   Por isso,  a opinião da equipe em relação à estrutura do projeto também deve ser avaliada, para tornar a atividade de gerenciamento de projetos mais fácil e natural.</p>
<p><strong>Requerimentos e padrões</strong></p>
<p>Várias empresas podem ter metodologias, requerimentos gerenciais e processos que influenciem o nível de detalhamento do escopo e atividades de um projeto.  O Gerente de Projeto deve ter o bom senso de adotar aqueles que realmente fazem sentido para seu projeto, e trabalhar na flexibilização ou modificações de padrões que só adicionem burocracia ou não tenham nenhum objetivo prático.</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/01/23/nivel_detalhamento_projeto_escopo_atividades/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Lidando com Personagens de Projetos – O Aliado</title>
		<link>http://ogerente.com/stakeholder/2008/01/16/lidando-com-personagens-de-projetos-%e2%80%93-o-aliado/</link>
		<comments>http://ogerente.com/stakeholder/2008/01/16/lidando-com-personagens-de-projetos-%e2%80%93-o-aliado/#comments</comments>
		<pubDate>Wed, 16 Jan 2008 18:56:18 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Equipe]]></category>

		<category><![CDATA[Recursos Humanos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/01/16/lidando-com-personagens-de-projetos-%e2%80%93-o-aliado/</guid>
		<description><![CDATA[
 

O último personagem dos projetos é O Aliado.
Descrição
O aliado é o profissional que todo Gerente de Projeto gosta de ver na equipe.  Suas principais características são:

Segue a metodologia do projeto.
Apóia os objetivos do projeto.
Adota uma comunicação clara e eficiente com o Gerente de Projeto e a equipe como um todo.
Assume suas responsabilidades e [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p align="center"><img class="aligncenter size-full wp-image-105" title="personagens-aliado" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/personagens-aliado.jpg" alt="" width="90" height="90" /></p>
<p>O último <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">personagem dos projetos</a> é O Aliado.</p>
<p><strong>Descrição</strong></p>
<p>O aliado é o profissional que todo Gerente de Projeto gosta de ver na equipe.  Suas principais características são:</p>
<ul>
<li>Segue a metodologia do projeto.</li>
<li>Apóia os objetivos do projeto.</li>
<li>Adota uma comunicação clara e eficiente com o Gerente de Projeto e a equipe como um todo.</li>
<li>Assume suas responsabilidades e entende a importância de sua atuação no projeto.</li>
</ul>
<p><strong>Como identificá-los</strong></p>
<p>O Gerente de Projeto deve ter cuidado, porque muitos <a href="http://ogerente.com/stakeholder/2008/01/06/lidando-com-personagens-de-projetos-%e2%80%93-o-falso/" target="_blank">profissionais Falsos</a> tentam se passar por aliados.  No entanto, não é difícil identificar verdadeiros aliados, já que eles possuem um diferencial claro: entregam resultados ao invés de ficar só na conversa ou dando desculpas.</p>
<p>Com o tempo é possível filtrar os verdadeiros aliados daqueles aliados “por conveniência” (que somente ajudam por um interesse de curto prazo, mas mudam de posição com qualquer alteração na situação).</p>
<p><strong>Como Agir</strong></p>
<p>Sempre que possível (especialmente quando o Gerente tem suficiente poder de decisão e participa da seleção da equipe do projeto), o projeto deve estar permeado de pessoas com este perfil.   Isto torna a equipe unida e produtiva.</p>
<p>O Gerente de Projeto deve corresponder às expectativas do aliado.  Se ele está ajudando e apoiando o projeto, nada mais correto do que oferecer o mesmo tipo de transparência e lealdade.</p>
<p>Estes profissionais devem fazer parte do círculo de confiança de qualquer Gerente, já que eles serão as peças-chave para que os objetivos do projeto sejam cumpridos com sucesso.</p>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/01/16/lidando-com-personagens-de-projetos-%e2%80%93-o-aliado/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Lidando com Personagens de Projetos – O Falso</title>
		<link>http://ogerente.com/stakeholder/2008/01/06/lidando-com-personagens-de-projetos-%e2%80%93-o-falso/</link>
		<comments>http://ogerente.com/stakeholder/2008/01/06/lidando-com-personagens-de-projetos-%e2%80%93-o-falso/#comments</comments>
		<pubDate>Sun, 06 Jan 2008 23:14:15 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Equipe]]></category>

		<category><![CDATA[Recursos Humanos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2008/01/06/lidando-com-personagens-de-projetos-%e2%80%93-o-falso/</guid>
		<description><![CDATA[
 


O quinto personagem dos projetos é O Falso:
Descrição
Trata-se daquela pessoa que finge apoiar o projeto e as idéias das pessoas, mas seus interesses são outros e faz de tudo para minar as atividades sem se expor.  A falsidade pode ser aplicada em diversas situações:

Com pessoas (fingindo amizades, “puxando o saco”, torcendo internamente pelo [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p align="center">
<p align="center"><img class="aligncenter size-full wp-image-107" title="personagens-falso" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/personagens-falso.jpg" alt="" width="90" height="90" /></p>
<p>O <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">quinto personagem dos projetos</a> é O Falso:</p>
<p><em><strong>Descrição</strong></em></p>
<p>Trata-se daquela pessoa que finge apoiar o projeto e as idéias das pessoas, mas seus interesses são outros e faz de tudo para minar as atividades sem se expor.  A falsidade pode ser aplicada em diversas situações:</p>
<ul>
<li>Com pessoas (fingindo amizades, “puxando o saco”, torcendo internamente pelo fracasso dos outros)</li>
<li>Com atividades (dando desculpas para fugir daqueles “pepinos”)</li>
<li>Com o projeto em si (disfarçando seu desejo pelo fracasso)</li>
</ul>
<p>A atuação deste tipo de profissional em torno do projeto pode ser extremamente danosa.  Se for uma pessoa inteligente e esperta, poderá causar danos e discórdias e ainda sair ileso da situação.</p>
<p><em><strong>Como Identificá-los</strong></em></p>
<p>Nem sempre é fácil identificar uma pessoa falsa, especialmente quando ela é boa nisso.</p>
<ul>
<li>Se você desconfia de alguém, puxe bastante conversa com essa pessoa e dê muita atenção a tudo que diz.   Eventualmente você notará que em situações diferentes ela age de forma distinta.</li>
<li>Use seus contatos de confiança para descobrir se a pessoa está falando mal dos outros ou do projeto pelas costas.  O falso se alimenta da criação de discórdia, mas dificilmente terá controle sobre todos os relacionamentos entre os stakeholders.</li>
<li>Plante armadilhas.  Crie situações na qual o falso possa exibir suas características, e concorde com ele.   Isto funciona especialmente com os menos experientes.</li>
</ul>
<p><strong><em>Como Agir</em></strong></p>
<ul>
<li>Junte provas.  Não me refiro a gravar ou filmar a pessoa, mas tenha fatos concretos que mostrem sua falsidade.</li>
<li>Encare o falso.  Mostre a ele que sua atitude não será aceita.  Ao encará-lo, ele tentará mostrar que você está imaginando coisas, e os somente fatos coletados poderão derrubá-lo.</li>
<li>Mantenha a firmeza.  Um falso habilidoso se apoiará em outros (aliados ou ingênuos) para justificar que não está agindo de forma errada.  Se você titubear, o assunto morrerá e ele ainda terá a oportunidade de falar mal de você pelas costas.</li>
<li>Retire a pessoa do projeto ou reduza sua participação ao mínimo.</li>
</ul>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2008/01/06/lidando-com-personagens-de-projetos-%e2%80%93-o-falso/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Lidando com Personagens de Projetos – O Trágico</title>
		<link>http://ogerente.com/stakeholder/2007/12/28/lidando-com-personagens-de-projetos-%e2%80%93-o-tragico/</link>
		<comments>http://ogerente.com/stakeholder/2007/12/28/lidando-com-personagens-de-projetos-%e2%80%93-o-tragico/#comments</comments>
		<pubDate>Sat, 29 Dec 2007 01:37:41 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Equipe]]></category>

		<category><![CDATA[Recursos Humanos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2007/12/28/lidando-com-personagens-de-projetos-%e2%80%93-o-tragico/</guid>
		<description><![CDATA[
 


O quarto personagem dos projetos é O Trágico:
Descrição
É aquele profissional que ao menor sinal de problema trata a situação como uma crise intransponível.   Sua máxima é “aonde há fumaça, há fogo”.   Para ele, os problemas não são naturais de um projeto, são o primeiro sinal do fracasso.
Existe mais de um [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p align="center">
<p align="center"><img class="aligncenter size-full wp-image-109" title="personagens-tragico" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/personagens-tragico.jpg" alt="" width="90" height="90" /></p>
<p>O <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">quarto personagem dos projetos</a> é O Trágico:</p>
<p><strong>Descrição</strong></p>
<p>É aquele profissional que ao menor sinal de problema trata a situação como uma crise intransponível.   Sua máxima é “aonde há fumaça, há fogo”.   Para ele, os problemas não são naturais de um projeto, são o primeiro sinal do fracasso.</p>
<p>Existe mais de um tipo de trágico:</p>
<ul>
<li>Aquele que tem boas intenções, mas não sabe lidar bem com a pressão e com as dificuldades de executar um projeto.</li>
<li>Aquele que não gosta do projeto e fica procurando defeitos.</li>
</ul>
<p>O segundo tipo é mais perigoso para o projeto, mas os dois devem ser “tratados”.  Sua influência pode ser muito negativa, já de tanto ouvir a lamentação dos trágicos, os inseguros podem adquirir a mesma atitude.</p>
<p><strong>Como Identificá-los</strong></p>
<ul>
<li>Quando algo acontece fora do planejado, gostam de dizer “já imaginava”, “já sabia” ou “eu avisei”.   No entanto, nunca se preocuparam em definir ações preventivas.</li>
<li>Ao menor sinal de problemas, exibem um nível de stress elevado.  Sinal de que não conseguem lidar com as dificuldades.</li>
<li>Sempre se concentram no problema, e não na solução.</li>
<li>Muitas vezes é difícil identificá-los, porque nas reuniões de equipe mostram serenidade, mas nos bastidores ficam falando tudo que está errado para os colegas.</li>
<li>Não conhecem ou aceitam o gerenciamento de riscos.</li>
</ul>
<p><strong>Como Agir</strong></p>
<p>Após identificado, não é muito difícil lidar com este profissional, especialmente quando no fundo ele tem boas intenções.</p>
<ul>
<li>Comece com uma boa conversa.  Diga a ele como sua atitude em relação às dificuldades atrapalha o projeto e afeta negativamente a equipe.  Explique técnicas de gerenciamento de riscos para que ele entenda que existe metodologia por trás da resolução de problemas e que estas situações são naturais em um projeto.</li>
<li>Se a conversa não funcionar, mostre à equipe o oposto da atitude que este profissional está exibindo.  Sempre que ele levantar um problema, mostre como buscar soluções.   Sempre que ele mostrar sinais de desespero, mostre firmeza e serenidade.  A equipe notará isto e certamente o apoiará o líder do projeto.</li>
</ul>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2007/12/28/lidando-com-personagens-de-projetos-%e2%80%93-o-tragico/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Lidando com Personagens de Projetos – O Bonzão</title>
		<link>http://ogerente.com/stakeholder/2007/12/13/lidando-com-personagens-de-projetos-%e2%80%93-o-bonzao/</link>
		<comments>http://ogerente.com/stakeholder/2007/12/13/lidando-com-personagens-de-projetos-%e2%80%93-o-bonzao/#comments</comments>
		<pubDate>Thu, 13 Dec 2007 12:38:06 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Equipe]]></category>

		<category><![CDATA[Recursos Humanos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2007/12/13/lidando-com-personagens-de-projetos-%e2%80%93-o-bonzao/</guid>
		<description><![CDATA[
 
 


O terceiro personagem dos projetos é O Bonzão:
Descrição
Trata-se daquele profissional que se acha superior a todos, e as regras que valem na organização (e no projeto) não se aplicam a ele.  Isto pode ser devido a diversas razões:

Conhecimento .
Experiência (tempo na empresa).
Posição política dentro da organização (alto “QI”).
Simples e pura burrice.

Seja qual [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em><br />
<em><strong> </strong></em></p>
<p align="center">
<p align="center"><img class="aligncenter size-full wp-image-110" title="personagens-bonzao" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/personagens-bonzao.jpg" alt="" width="90" height="90" /></p>
<p>O <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">terceiro personagem dos projetos</a> é O Bonzão:</p>
<p><strong>Descrição</strong></p>
<p>Trata-se daquele profissional que se acha superior a todos, e as regras que valem na organização (e no projeto) não se aplicam a ele.  Isto pode ser devido a diversas razões:</p>
<ul>
<li>Conhecimento .</li>
<li>Experiência (tempo na empresa).</li>
<li>Posição política dentro da organização (alto “QI”).</li>
<li>Simples e pura burrice.</li>
</ul>
<p>Seja qual for o caso, a atitude deste tipo de pessoa é um fator de desagregação da equipe, gera insatisfação e stress, e seus efeitos devem ser mitigados pelo <a href="http://ogerente.com/stakeholder/category/gerente-de-projetos/" target="_blank">Gerente de Projeto</a>.</p>
<p><strong>Como identificá-los</strong></p>
<ul>
<li>Insistem em não seguir a metodologia e os procedimentos de projeto.</li>
<li>Gostam de citar (direta ou indiretamente) o bom relacionamento que têm com pessoas influentes na organização.</li>
<li>Usam sua experiência ou conhecimento como escudo para não ouvir a opinião dos outros e sempre querem impor suas idéias.</li>
<li>Na maioria das vezes adotam uma pose arrogante.</li>
</ul>
<p><strong>Como Agir</strong></p>
<p>O Gerente de Projeto deve ter muito cuidado ao lidar com este tipo de profissional.  Quando sua arrogância vem do conhecimento, experiência ou posição política, deve-se pensar friamente na melhor estratégia para integrá-lo na equipe ou expurgá-lo do projeto.  Algumas sugestões:</p>
<ul>
<li>Construa seu próprio capital político na empresa para se proteger em caso de conflitos.   Infelizmente algumas pessoas com este perfil não mudam sua atitude.</li>
<li>Procure conhecer melhor a pessoa e porque ela age desta forma.  Se você encontrar algo que a motive terá maior facilidade para lidar com ela.</li>
<li>Tente ter uma conversa com o profissional explicando sua importância no projeto, mas deixando claro que sua atitude pode influenciar negativamente outros membros da equipe.</li>
<li>Quando não encontrar um caminho para mudar ou excluir a pessoa, tente diminuir sua responsabilidade nas atividades e isole-o do resto da equipe.  Os outros membros devem notar que este tipo de atitude não é bem aceito.</li>
</ul>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2007/12/13/lidando-com-personagens-de-projetos-%e2%80%93-o-bonzao/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Lidando com Personagens de Projetos – O Inseguro</title>
		<link>http://ogerente.com/stakeholder/2007/11/28/lidando-com-personagens-de-projetos-%e2%80%93-o-inseguro/</link>
		<comments>http://ogerente.com/stakeholder/2007/11/28/lidando-com-personagens-de-projetos-%e2%80%93-o-inseguro/#comments</comments>
		<pubDate>Wed, 28 Nov 2007 13:21:01 +0000</pubDate>
		<dc:creator>Luiz de Paiva</dc:creator>
		
		<category><![CDATA[Equipe]]></category>

		<category><![CDATA[Recursos Humanos]]></category>

		<guid isPermaLink="false">http://ogerente.com/stakeholder/2007/11/28/lidando-com-personagens-de-projetos-%e2%80%93-o-inseguro/</guid>
		<description><![CDATA[
 

O segundo personagem dos projetos é O Inseguro:
Descrição
O inseguro é aquele profissional que vê o projeto como uma mudança ao status quo, e não sabe se adaptar à nova situação.   Seu medo  pode ver de diversos fatores:

Não está acostumado a trabalhar com processos eficientes de gerenciamento de projetos.
Não possui a autoridade [...]]]></description>
			<content:encoded><![CDATA[<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Sup");
// --></script><br />
<em><strong> </strong></em></p>
<p style="text-align: center;"><img class="aligncenter size-full wp-image-113" title="personagens-inseguro" src="http://ogerente.com/stakeholder/wp-content/uploads/2008/08/personagens-inseguro.jpg" alt="" width="90" height="90" /></p>
<p>O segundo <a href="http://ogerente.com/stakeholder/2007/11/07/lidando-com-personagens-de-projetos/" target="_blank">personagem dos projetos</a> é O Inseguro:</p>
<p><strong>Descrição</strong></p>
<p>O inseguro é aquele profissional que vê o projeto como uma mudança ao <em>status quo</em>, e não sabe se adaptar à nova situação.   Seu medo  pode ver de diversos fatores:</p>
<ul>
<li>Não está acostumado a trabalhar com processos eficientes de gerenciamento de projetos.</li>
<li>Não possui a autoridade que gostaria de ter no projeto.</li>
<li>O produto do projeto traz insegurança para sua situação na empresa.</li>
</ul>
<p>Independente do fator que causa a insegurança, os resultados são os mesmos:  baixa produtividade, resistência e riscos adicionais para o projeto.   Este tipo de membro da equipe pode ser extremamente prejudicial ao projeto, e cabe ao <a href="http://ogerente.com/stakeholder/category/gerente-de-projetos/" target="_blank">Gerente de Projeto</a> buscar meios de mudar sua atitude.</p>
<p><strong>Como identificá-los</strong></p>
<ul>
<li>Não seguem os processos definidos para o projeto.</li>
<li>Expressam (direta ou indiretamente) uma visão negativa em relação ao produto do projeto.</li>
<li>Passa grande parte do tempo criticando tudo e todos.</li>
<li>Gosta de lançar problemas ao ar ao invés de buscar soluções.</li>
</ul>
<p>O Gerente de Projeto deve identificar possíveis profissionais com este perfil no começo do projeto.  Realizando uma análise do projeto e de seu produto, em relação à estrutura organizacional da empresa, é possível ver quem poderá ser afetado negativamente.</p>
<p><strong>Como Agir</strong></p>
<ul>
<li>Se possível, não incluir estes profissionais na equipe do projeto.</li>
<li>Ter uma conversa franca com a pessoa.   Na maioria das vezes ela não tem más intenções, e vocês podem chegar a um consenso sobre o que é melhor para todos.</li>
<li>Exigindo rigorosamente o cumprimento dos processos do projeto.</li>
<li>Restringindo as tentativas do Inseguro de falar mal das pessoas e do projeto, deixando claro que você exige uma atitude positiva.</li>
<li>Mostrando segurança e liderança nos momentos que ele expressar sua insegurança (especialmente em frente à equipe do projeto).</li>
</ul>
<p><script type="text/javascript"><!--
  GA_googleFillSlot("Stakeholder_Post_Inf");
// --></script><br />
<em><strong> </strong></em></p>
]]></content:encoded>
			<wfw:commentRss>http://ogerente.com/stakeholder/2007/11/28/lidando-com-personagens-de-projetos-%e2%80%93-o-inseguro/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
