Classificação de Projetos

 

Classificação de Projetos

Segue uma sugestão de leitura sobre como fazer a classificação (bem-humorada) dos projetos problemáticos:

http://elirodrigues.com/2011/10/13/modelo-bem-humorado-para-classificacao-de-projetos-problematicos/

Boa Leitura!

@gerestrategico

Metodologia ágil ou tradicional: porque não as duas?

Os modelos ágeis de gestão vem ganhando cada vez mais espaço nas organizações, mas nem sempre são bem aceitas ou entendidas por gerentes/executivos acostumados com o gerenciamento de projetos no modelo tradicional (em cascata, ou waterfall). As discussões sobre vantagens e desvantagens de cada modelo são, muitas vezes, inflamadas e polarizadas, onde cada um dos lados tenta doutrinar o outro.

Por mais que cada modelo ofereça uma série de vantagens e desvantagens (que devem ser avaliadas por cada organização e, mais especificamente, cada tipo de projeto) o que eu tenho visto é que a implementação “pura” de um modelo ou de outro é muito rara. Poucos são os lugares onde o gerenciamento do projeto segue dogmaticamente os preceitos (“boas práticas”) listadas no PMBoK ou que executem todos os seus projetos usando Scrum, por exemplo. Se olharmos criticamente um conjunto de projetos de determinada empresa é muito provável que vejamos a utilização de práticas de ambos modelos.

O objetivo desse post é compartilhar uma experiência onde tive a oportunidade de trabalhar com os dois modelos simultaneamente no mesmo projeto, e discutir sobre os ganhos percebidos, dificuldades encontradas e adaptações (tailoring) necessárias.

Histórico do projeto

O projeto tratava do desenvolvimento de uma inovação em um produto do cliente, cuja janela de inserção no mercado era bem definida (e restrita). Os requisitos do sistema, por sua vez, eram bastante complexos, e ainda não totalmente especificados (o que ocorreu ao longo do projeto).

Devido à importância estratégica do projeto o cliente necessitava validar entregas parciais e ter algumas funcionalidades implementadas em versões de demonstração do produto para ser utilizado em “Road Shows”. Assim, uma das ações para garantir a execução desse trabalho foi o estabelecimento de um contrato para a alocação de um time de tamanho fixo durante um período determinado.

Considerando as características do projeto o modelo de desenvolvimento escolhido foi o Scrum, uma vez que este permitiria tratar o desenvolvimento do produto de forma incremental e ainda assim garantir a qualidade do produto e do processo (outro requisito importante para o cliente).

No entanto, apesar de entender o funcionamento do modelo “puro” do Scrum o cliente demandou um acompanhamento nos moldes tradicionais, considerando um projeto “waterfall” e artefatos previstos no modelo de maturidade CMMi. Com isso, por exemplo, foram criados o cronograma macro de entregas descrito em um gráfico de Gantt, algumas métricas de acompanhamento de valor agregado e relatórios de status semanais.

Desafios

Em virtude dessa gestão “mista” foi necessário avaliar processos e práticas das duas correntes de pensamento e avaliar criticamente o uso das mesmas no projeto, tendo em mente a não duplicação do trabalho e a otimização do tempo e esforço para a gestão do projeto, com a garantia do atendimento das expectativas dos stakeholders.

Como resultado dessa análise alguns processos tiveram de ser adaptados. Já alguns outros continuaram a ser executados da mesma maneira, uma vez que o resultado produzido era o mesmo ou não apresentava diferenças significativas usando um dos métodos.

Os ajustes no processo foram sendo feitos e validados com o cliente ao longo do projeto, com o consequente mapeamento das práticas e grupos de processos de modo a gerenciar o projeto de forma eficiente.

A prática 

As principais disciplinas exercidas durante o projeto estão listadas a seguir, juntamente com uma explanação de como elas foram executadas.

Gestão do escopo

O escopo do projeto foi dividido em pacotes de trabalho, sendo que cada requisito foi detalhado pelo analista de requisitos para a criação do product backlog do projeto. No entanto, diferentemente de um projeto ágil puro, toda a quebra dos requisitos em estórias e atividades foi feita durante o planejamento do projeto e o backlog resultante foi usado como guia para o planejamento das iterações (sprints).

Quaisquer mudanças nos requisitos do projeto, seja por entendimento dos mesmos ou por alteração do escopo original, foram tratadas através de um procedimento de “Solicitações de Mudança” (Change Requests), onde as mudanças eram analisadas, detalhadas e incluídas no product backlog.

Gestão do cronograma

Apesar do projeto ter sido executado usando Scrum o conteúdo de cada iteração foi definido com base na priorização do backlog feita pelo Product Owner ainda durante a fase de planejamento. Como o conteúdo de cada iteração estava, em grande parte, definido de antemão a reunião de planejamento de cada sprint focava no balanceamento de volume de trabalho (esforço) e força produtiva disponível (capacidade), além de fazer adaptações necessárias na velocidade do time e incorporação de atividades remanejadas de outros sprints.

Como o Gerente de Projetos do cliente precisava ter visibilidade do projeto como um todo, foi criado um cronograma no MS-Project para acompanhar a execução de cada requisito, sendo que os milestones definidos continham um subconjunto de requisitos que seriam implementados. O cronograma era acompanhado com base no progresso dos sprints, e servia como referência para coleta de métricas do projeto.

O acompanhamento do projeto se dava tanto pelo cronograma de funcionalidades quanto pelo gráfico de burndown de cada sprint. Os dados do cronograma eram usados para informar o progresso do projeto como um todo, enquanto o burndown indicava o progresso de cada sprint.

Gestão do custo

Como o time de projeto era fixo a gestão dos custos do projeto limitou-se ao controle de despesas, o que simplificou a tarefa. Os índices de valor agregado derivavam diretamente dos dados inseridos no MS-Project.

Gestão da comunicação

O plano de comunicação foi criado no início do projeto após a identificação de todos os stakeholders. Para cada tipo de informação a ser divulgada foi definida a periodicidade e sua audiência, bem como o propósito e o responsável pela coleta e divulgação de cada informação. O time de projeto era informado regularmente através das reuniões diárias e demais cerimônias (planning, review) do sprint. Já a alta gerência e o cliente eram informados através de relatórios semanais de progresso.

Um mapa com papéis e responsabilidades de cada stakeholder foi criado e divulgado, de modo a tornar público todos os canais de informação do projeto.

Gestão de riscos

O processo de identificação e análise qualitativa dos riscos, bem como o planejamento de resposta aos mesmos, seguiu o processo tradicional, com o uso de uma planilha de acompanhamento atualizada semanalmente, sendo que o time e demais stakeholders eram envolvidos no processo através das reuniões diárias, reuniões periódicas de status e cerimônias do Scrum.

Gestão da qualidade

O projeto seguiu um processo de desenvolvimento aderente ao CMMi e foi acompanhado por um analista da área de Qualidade, que auditava periodicamente (a cada final de sprint) as entregas (artefatos) do mesmo. A qualidade era garantida através da criação e acompanhamento de itens de “Não Conformidade” em ferramenta específica, que eram enviados ao cliente mensalmente.

Gestão de RH:

A alocação de pessoas foi facilitada pelo fato do time ter um tamanho fixo ao longo de todo o projeto. Como a estrutura da empresa é do tipo matricial o gerente funcional era responsável pela alocação das pessoas, mas uma vez definido o time com as habilidades necessárias (com base no escopo definido) o esforço de gestão foi reduzido, limitando-se ao planejamento e controle de ausências ocasionais e períodos de férias, bem como, obviamente, ao acompanhamento do desempenho dos membros da equipe.

Gestão de aquisições:

Não foi necessário durante o projeto.

Conclusão

A amostra de projetos executados com essa metodologia é pequena e limitada aos projetos que eu gerenciei para esse cliente específico mas, apesar do trabalho inicial de análise ter tomado algum tempo, os resultados foram bastante satisfatórios.

O gerente de projetos do cliente ficou satisfeito por ter a visibilidade que precisava, e os produtos dos projetos foram entregues no prazo e com qualidade necessária. Um resultado adicional, que comprova a eficiência do modelo, é que ele tem sido adotado inclusive por outros parceiros com quem esse cliente executa projetos.

E você, tem alguma experiência desse tipo?

Eamon Sousa

Posts relacionados:

• Gerenciando projetos ágeis
• Análise de processos
• Projeto de adoção do Scrum
• Gestão de Projetos: Operacional x Estratégico
• PMBOK x SCRUM: como gerenciar um projeto de software?

Trabalho em Equipe e o Paradoxo de Abilene

Não é novidade dizer que problemas de comunicação nas empresas e nas equipes de trabalho causam interferências nas organizações e, em especial, nos projetos.

Tornar a comunicação eficaz é um desafio diário. A interação entre os interlocutores através dos canais e ferramentas de comunicação disponíveis (reuniões, conferências telefônicas, workshops, etc.) e, principalmente, os problemas causados pelas barreiras da comunicação (tais como ruídos, bloqueios, filtros pessoais, interferências, pressupostos, preconceitos, etc.), tornam este desafio ainda mais complexo.

Neste contexto, quando falamos do trabalho de equipe nos projetos, um dos problemas que pode acarretar em falhas na comunicação é conhecido como Paradoxo de Abilene, descrito por Jerry B. Harvey. Em seu enunciado, Harvey diz que “o consenso que é formado por um grupo de indivíduos é oposto à vontade de cada um individualmente”.  Por exemplo, você pode não querer participar de um evento qualquer, ou não concordar com as decisões tomadas em grupo, mas, por acreditar que existe um concenso entre os demais, acaba por ceder e dar sua anuência no assunto (sem no entanto, realmente se comprometer devidament). Entretanto, quando as pessoas começam a interagir e a manifestar suas ideias e opiniões, é que se nota que todos (ou a grande maioria) não queria estar ali ou discorda das determinações estabelecidas.

Então, vamos tratar especificamente do ambiente de execução projetos e tomando como base uma reunião de início de projeto. Neste momento, onde temos maior liberdade para delimitar os objetivos mais adequados para o projeto (quando os impactos das mudanças no projeto são menores) de modo a atingir as expectativas dos stakeholders envolvidos, é extremamente importante que a comunicação entre as partes seja fluida e efetiva. Ou seja, é importante garantir que todos estejam ‘sintonizados’ e comprometidos com os planos que estão sendo desenvolvidos/estabelecidos.

Nesta hora de definições, onde é importante garantir que as demandas das partes interessadas sejam devidamente ententidas, e também que todos se comprometam com os objetivos do projeto, é que as habilidades de comunicação, negociação e integração do gerente tornam-se essenciais para garantir o sucesso do projeto.

Para isso, o gerente do projeto deve analisar todos os aspectos da comunicação que envolvem a transmissão e recepção da informação (mensagem). Entre estes:

• O código utilizado: cuidar para que o idioma, jargão e gírias sejam devidamente entendidos por todos.
• As culturas envolvidas: evitar que diferentes modo de pensar e interpretar a informação, causem desvios de entendimento;
• A mensagem: garantir para que as informações (reports, acordos, etc.) sejam claros e objetivos. Além disso, pode lançar mão da utilização de diferentes recursos (textos, gráficos, tabelas) para tornar a mensagem bastante clara;
• O método: a fala, a escrita, as apresentações, as reuniões, enfim, é preciso avaliar a complexidade e quantidade de informações e utilizar de diferentes métodos para transmiti-las;
• A técnica: gestos, posturas, recursos (visuais, áudio). Quando o projeto conta com equipes dispersas geograficamente, a comunicação verbal requer especial cuidado;
• Feedback: observar as reações ( fisionomias) e interesse da plateia é importante recurso de avaliação da efetividade da comunicação. Além disso, pode-se também solicitar que determinadas pessoas  manifestem seu entendimento (o que é bastante interessante quando existem equipes ‘virtuais’ envolvidas).

E como se prevenir ou evitar que situações parecidas com o Paradoxo de Abilene ocorram no seu projeto?

• Proporcione um ambiente que incentive todos a expor suas idéias, garantindo que existe um correto entendimento da informação.
• Garanta que todos sejam ouvidos. Solicite feedback de cada um.
• Questione os “por quês” de cada opinião. O objetivo não é por em dúvida os argumentos, mas sim, fazer com que tudo seja devidamente apresentado e entendido.
• Instigue e envolva os participantes de modo a garantir que o projeto tem efetivamente seu comprometimento com os objetivos.
• Promova o debate. As discussões podem levar a um melhor entendimento dos aspectos do projeto sob diferentes pontos de vista.
• Integre as idéias. Faça com que todas as opiniões se juntem para os objetivos comum do projeto.

Enfim, é preciso fazer da comunicação uma importante aliada para o sucesso do projeto, e não uma fonte de geração de problemas potenciais.

Livro: The Abilene Paradox and other Meditation on Management

Concurso: O Paradoxo de Abilene foi tema de um concurso do BNDES em Março/2011.

Giovani Faria

Meus posts

Gestão da Comunicação – Paradoxo de Abilene

O post sobre o Paradoxo de Abilene, sua influência sobre os projetos e maneiras de evitá-lo foi atualizado.

Boa Leitura:

http://gerenciamentoestrategico.wordpress.com/2011/04/23/trabalho-em-equipe-e-o-paradoxo-de-abilene/

Obs.: O Paradoxo de Abilene foi tema de um concurso do BNDES:

http://www.cesgranrio.org.br/eventos/concursos/bndes0111/pdf/bndes0111_discursiva.pdf

Giovani Faria

Meus posts

Gerenciamento “Ovo de Colombo”

Por Giovani Faria

Hoje vi uma “twittada” do @gerentenobuteco onde é mencionada a expressão “Ovo de Colombo” que denota que algo que seria óbvio e, até mesmo trivial, desde que, alguém já tivesse feito (dito, conseguido, etc.).

Pois bem, com esta frase na cabeça comecei a me questionar sobre o que poderia ser o “Ovo de Colombo” do gerenciamento de projetos. Algo que, em princípio, ninguém tivesse afirmado, feito ou sequer conseguido.

Tarefa (ou ambição) bastante complexa esta. Então, para aproveitar a expressão, vou apresentar aqui algumas frases que, bem, não deixam de ser “Ovos de Colombo” (talvez, tenha criado aqui alguns neologismos).

Seguindo a sequência das áreas de conhecimento do PMBoK:

• Gerencie a Integração COORDENADAMENTE.
• Gerencie o Escopo CRITERIOSAMENTE.
• Gerencie o Tempo CUIDADOSAMENTE.
• Gerencie os Custos CONSERVADORAMENTE.
• Gerencie a Qualidade METODICAMENTE.
• Gerencie as Pessoas PACIENTEMENTE.
• Gerencie as Comunicações FLUIDAMENTE.
• Gerencie os Riscos PREVENTIVAMENTE.
• Gerencie as Aquisições CONTRATUALMENTE.

Além disso, seguindo os grupos de processo:

• Inicie CONJUNTAMENTE.
• Planeje INTERATIVAMENTE e RECURSIVAMENTE.
• Execute CONSISTENTEMENTE.
• Monitore FREQUENTEMENTE.
• Encerre DOCUMENTADAMENTE.

Obviamente que é necessário também avaliar CONSTANTEMENTE.

Giovani Faria

Minha lista de posts

@gcfaria

Série Riscos em Projetos – Parte 1

Introdução

Quando falamos de riscos em projetos podemos nos lembrar da famosa Lei de Murphy. Algumas versões são:

• “Se alguma coisa pode dar errado, com certeza dará”.
• “Se houver mais de uma maneira de se executar uma tarefa ou trabalho, e se uma dessas maneiras resultar em catástrofe ou em consequências indesejáveis, certamente essa será a maneira escolhida por alguém para executá-la.”

Embora com palavras nada otimistas, esta conhecida lei acaba sendo comprovada nas mais diversas situações e, mais especificamente, nos projetos.

Quando falamos de gerenciamento de projetos, estamos nos referindo ao gerenciamento da Integração de diferentes áreas tais como: Escopo, Custos, Tempo (prazo), Qualidade, Pessoas, Comunicações, Aquisições e Riscos. Que por sua vez, devem estar alinhadas com a estratégia organizacional.

Com tantos aspectos para gerenciar – de forma integrada – fica evidente que a probabilidade de que Murphy se faça ‘presente’ em seu projeto é bastante alta.

A questão principal é: Como se precaver e se antecipar aos potenciais problemas? Como ‘vencer’ Murphy?

Uma resposta imediata seria Planejamento e, em especial, atuação plena no Gerenciamento de Riscos.

Quando tratamos do Gerenciamento de Riscos (Planejamento, Identificação, Análise, Monitoramento e Controle) é importante entender qual o perfil de risco de sua organização? Abaixo, alguns exemplos:

• Em projetos de pesquisa, as instituições aceitam um alto grau de risco, uma vez que os investimentos em novas tecnologias não necessariamente podem trazer resultados, especialmente no curto prazo.
• Já nos projetos incrementais de desenvolvimento de produtos, onde novas funcionalidades são incluídas, a aceitação dos riscos é moderada. Isto é, a empresa trabalha na evolução de um produto que já possui um determinado mercado.
• Finalmente, nos projetos de customização contratados por um cliente qualquer, a aceitação de riscos é extremamente baixa, uma vez que muito provavelmente a organização executora será responsável pelos resultados do projeto.

Entretanto, estamos falando de situações e circustâncias que, muitas vezes, estão fora de seu controle. Por exemplo:

• pessoas de seu projeto deixando a empresa;
• problemas com infraestrutura e com as ferramentas de suporte ao projeto;
• entendimento incorreto de requisitos ou prioridades;
• estimativas incorretas, etc.

A lista é imensa e, provavelmente, estará sempre incompleta. Então, mais do rever constantemente a lista de riscos para incluir novos itens, o principal desafio é tratá-los (monitorar e atuar) corretamente.

Avaliação de Riscos – Parte 2

Giovani Faria

Motivação, Criatividade, Espírito de Equipe

Imaginemos a seguinte situação: 

Um determinado projeto tem o período de execução de um ano. Ao final desse período,  os “entregáveis” desse projeto serão apresentados durante exatos 90 minutos a toda população enquanto uma equipe altamente especializada se encarrega da avaliação formal dos resultados projeto e escolhe o melhor entre os concorrentes.

Outra premissa desse projeto é que não haverá tempo para nenhum tipo de retrabalho ou reapresentação dos resultados.

Outras limitações de projeto são conhecidas, sendo que a principal dela é o budget disponível para a execução do projeto não ser suficiente para comportar os salários de todos  colaboradores envolvidos, mas todos eles estarão diretamente comprometidos com o resultado final do projeto.

- Existem projetos assim? – Sim!

Imaginaram como manter o comprometimento do grupo durante a execução do projeto e como exigir criatividade e espírito de equipe daqueles envolvidos no projeto? Mesmo sabendo que uma das premissas é ter que contribuir de forma voluntária? E que na apresentação do produto final não haveria espaço para desculpas ou re-entregas?

Isso realmente acontece, e acontece no Brasil, todos os anos, e em empresas sem fins lucrativos denominadas Escolas de Samba. Tudo é muito parecido com qualquer outro projeto: cronograma, planejamento, organização, direção, parcerias, reuniões e etc.

Essas empresas, escolas de samba, possuem profissionais altamente motivados, com criatividade e espírito de equipe, que é justamente o que as organizações buscam, principalmente em tempos de crise. O segredo do sucesso está no modo como os componentes acreditam no que fazem. Sabem que são importantes. E que a vitória depende deles. A união da equipe é o maior fator para se alcançar esses resultados. O trabalho coletivo é valorizado nas escolas de samba.

Diferentemente do que acontece  em muitas empresas, nas escolas de samba há um envolvimento emocional muito grande por parte de todos os componentes. Muitas vezes é isso que falta às empresas.

O sucesso do carnaval quando comparado com outros projetos mostra a aplicação de um moderno modelo gerencial-organizacional:

a) administração descentralizada – cada setor (ala) é administrado como se fosse um sub-projeto;

b) participativo – todos opinam, todos sugerem mudanças e as mudanças aprovadas são implementadas;

c) interdependentes – uma ala deve estar integrada e em harmonia com o resto da escola, o gerenciamento de integração é essencial nesse quesito.

Outro ponto importante no sucesso é transparência de objetivos, não há como se envolver com um idéia sem conhecê-la. Apesar de parecer simples,  muitas empresas não tem a cultura de compartilhar suas metas com os funcionários. É preciso que os objetivos pessoais estejam ligados aos objetivos coletivos, pois só através do trabalho  de equipe coordenado é que torna-se possível  alcançar os objetivos propostos.

Com o objetivo de tomar decisões e resolver problemas mais rapidamente, a administração participativa motiva as relações de trabalho e sua aplicabilidade na política de administração de recursos humanos. Os funcionários apresentam suas expectativas e contribuem com suas experiências e conhecimentos, buscando agregar valores às funções e demais integrantes da equipe, e melhorar o  desempenho do trabalho.

No universo de uma escola de samba para atingir um bom resultado na avenida é necessário saber administrar riscos. As pessoas precisam aprender com os próprios erros. Errar naquilo que se conhece é imperdoável, mas errar à procura do novo é bom, e deve ser incentivado. Porque se você não arriscar, nunca conseguirá, melhorar seus resultados.

Objetivos estratégicos, estruturas organizacionais, tecnologia e recursos humanos são fatores essenciais ao desenvolvimento e  crescimento de qualquer empresa. Aliados a isso, pitadas de motivação, criatividade e espírito de equipe são diferenciais competitivos e indicadores de sucesso na condução de projetos.

Abraços, confetes e serpentinas a todos,

Marcelo

Lições Aprendidas (Case) – Parte 3/4

Lições Aprendidas – Parte 3/4

Link para Parte 2/4

Integração

A integração foi maior desafio do projeto. Alguns dos fatores mais relevantes foram:

• stakeholders: grande número e dispersos geograficamente
• comunicação: constante e intensa, com reuniões semanais (técnicas e administrativas) via conferência telefônica. Além das reuniões coletivas, discussões direcionadas a cada uma áreas tinham que ser conduzidas para atuar em demandas específicas.
• relatórios: embora também seja um item de comunicação, foi colocado propositadamente à parte para mostrar a importância de manter os stakeholders (principalmente os que não atuam diretamente na execução do projeto) informados sobre o andamento do projeto. Nesta categoria, além do requisitante do projeto (e sponsor), se enquandra também o nível gerencial organizacional.
• dependências: necessidade de interação constante entre áreas de desenvolvimento (8) com impactos dependentes. Ações específicas foram criadas para garantir o alinhamento de informações relacionadas aos requisitos.
• cultural: uma preocupação constante foi a diferença cultural que exigiu cuidados, principalmente, na comunicação. As informações reportadas eram discutidas constantemente para garantir a efetividade da comunicação.
• conflitos: a demanda por recursos e a concorrência com outros projetos foi inevitável, e os conflitos também. Nesta hora, a atuação dos stakeholders do nível gerencial organizacioal foi bastante importante e decisiva, garantindo a alocação necessária de recursos para o projeto

De acordo com o PMBoK, o Gerenciamento da Integração do Projeto “inclui os processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de processos de gerenciamento”.

Agora, passado o projeto, fica evidente a importância do Gerenciamento da Integração do Projeto, que nas palavras do PMBoK “…requer que sejam feitas escolhas sobre alocação de recursos, consessões entre objetivos e alternativas conflitantes e gerenciamento de dependências mútuas….”

Neste sentido, uma ação que se mostrou bastante efetiva foi a de colocar os stakeholders principais juntos (neste caso, por 2 dias) para efetuar o planejamento do projeto. Neste momento, ficou claro que, desde o solicitante do projeto, passando pela equipe de gerenciamento e de desenvolvimento (execução) até o pessoal responsável pela verificação, que todos precisavam contribuir (e em alguns pontos, ceder) para o atingimento de uma das principais metas do projeto que, naquele momento, estava focada na data de entrega, obviamente, sem redução de escopo.

• Link para Parte 1/4
• Link para Parte 2/4

Abraço, Giovani Faria

Continuação: Lições Aprendidas (Case) – Parte 4/4

Dividir para Conquistar

Esta foi uma tática de guerra de sucesso empregada na expansão do domínio Império Romano. Grupos ou facções com interesses diferentes eram ‘corrompidos’ fragilizando a estrutura do país e facilitando a dominação Romana.

No Gerenciamento de Comunicações, temos stakeholders com interesses diferentes, que precisam ter suas expectativas gerenciadas e atendidas. Estes interessados podem, em maior ou menor grau, influenciar, e até mesmo prejudicar, o andamento do projeto. Negligenciar a existência de algum desses stakeholders ou não entender o seu grau de influência no projeto é fator crítico uma vez que falhar nessa análise pode causar impactos ao seu projeto. Neste momento, o gerente (e seu grupo de trabalho, se for o caso) deve analisar as demandas e necessidades desses stakeholders de modo a minimizar riscos para o projeto.

No Gerenciamento do escopo, os requisitos do projeto são transformados (divididos) em diferentes entregáveis (deliverables) da Estrutura Analítica do Projeto (EAP). Já no Gerenciamento de Tempo, todas essas atividades que compõem o conjunto de entregáveis devem ser estimadas, sequenciadas e seu andamento (cronograma) monitorado.

Neste contexto, quando trata-se de ciência da computação, dividir para conquistar refere-se a uma técnica de recursão utilizada onde o problema a ser resolvido é dividido em instâncias menores, que são executadas recursivamente e o resultado final é obtido combinando-se as soluções intermediárias. Esta dinâmica, influenciada pela grande competição do mercado, traz a necessidade de agilidade e da escolha correta do Ciclo de Vida do Projeto e suas respectivas fases.

E é no Gerenciamento de Integração que o plano de dominação – ou melhor, o plano de gerenciamento – desse Império, o projeto, ganha forma. E agora, cabe ao General, o Gerente de Projeto, liderá-lo e conduzi-lo ao sucesso.

Seu projeto não é o Império Romano, mas ainda assim, precisa ser conquistado.

Abraço, Giovani Faria.

Influência Cultural no Gerenciamento de Projeto

 A cultura tem forte influência em como um projeto pode atingir seus objetivos. Aspectos culturais e alguns estilos adotados são tratados dentro do time de projetos como “regras” e influenciam diretamente na maneira com a qual o trabalho é executado. É fácil gerenciar um projeto com grupos de trabalho com diferentes culturas? A resposta é não!

Fortemente influenciadas pela globalização, tanto pessoas quanto organizações expandiram suas atividades para além das fronteiras de seus países de origem, gerando uma exposição à diferentes hábitos e culturas. Embora não seja tarefa simples, cabe ao gestor do projeto ter a sensibilidade e a capacidade de integrar aspectos culturais gerais com as características culturais específicas de um determinada região.

 ”A cultura é mais frequentemente uma fonte de conflito do que de sinergia. As diferenças culturais são um incômodo na melhor das hipóteses e, muitas vezes um desastre.”  Professor Geert Hofstede, Professor Emérito da Universidade de Maastricht na Bélgica.  

A afirmação do professor Hofsted é no mínimo desafiadora; mas tirar proveito da diversidade cultural a partir da forma de pensar, agir e se comportar da equipe trará uma nova visão ao gestor de projetos. Seu sucesso criará um diferencial competitivo e estabelecerá laços de parceria dentro  do time de projeto. Transformar as adversidades e até mesmo as barreiras culturais em uma enriquecedora troca de experiências é, no mínimo, interessante para o desenvolvedor e de valor inestimável para o projeto e para a organização.

Abraços, Marcelo Camera