Conceitos de Gerenciamento de Projetos (Parte 3)

Olá pessoal, no post anterior sobre conceitos de Gerenciamento de Projetos, falei sobre o que é gerenciar projetos, porque gerenciar e também abordei a Restrição Tripla do Gerenciamento de Projetos, se quiserem, basta consultar as partes 1 e 2 nos links a seguir:

Parte 1: https://flavioaf.wordpress.com/2010/02/15/conceitos-de-gerenciamento-de-projetos-parte-1/

Parte 2: https://flavioaf.wordpress.com/2010/04/07/conceitos-de-gerenciamento-de-projetos-parte-2/

Porém, começamos esta parte com uma pergunta: Por que projetos fracassam?

Bom, acho que todo mundo já viu aquela famosa imagem, muito comum em apresentações e treinamentos sobre Gerenciamento de Projetos, principalmente na área de TI:

Essa imagem ilustra bem a falha no fluxo de comunicação entre os stakeholders de um projeto (cliente, gerente, equipe). Porém, apesar de essa geralmente ser a interpretação da tirinha, não é o único problema ilustrado. Na realidade, essa tirinha ilustra problemas em todas as áreas de conhecimento no Gerenciamento de Projetos, não apenas na comunicação.

Um fato comum em TI é o de que o cliente não tem a menor idéia do que quer. Sim, exatamente isso que você leu. O cliente não sabe o que quer, pois seus principais requisitos só ficam claros durante o uso. Por isso, o cliente da historinha explicou que queria um balanço, quando na verdade queria um pneu pendurado na árvore. Dessa forma, as metas e objetivos do projeto são mal formulados e o escopo fica muito distante do real valor que o projeto poderia agregar ao cliente.

O líder do projeto entende um escopo completamente diferente do que o cliente explicou e passa para o analista de negócios para especificar, e este gera outra interpretação completamente diferente. O analista especifica todo o projeto, com base na informação já errada que recebeu do líder/gerente do projeto e faz tudo isso sem sequer realizar outra reunião com o cliente!!! Depois o analista passa ao técnico que vai desenvolver o projeto, a especificação errada, que foi feita com base em informações inicialmente erradas! E o técnico desenvolve um produto completamente diferente do que o cliente esperava, e por aí o vai o telefone sem fio…

Ou seja, o projeto é tocado com informações insuficientes ou inadequadas! Dessa forma, ocorre uma grande fuga do escopo inicial do projeto, os prazos são mal estimados, os custos são mal estimados… Dessa forma, tudo sai do controle, afinal as métricas estão todas erradas!

Sem contar que o equilíbrio entre planejamento e execução muitas vezes é uma grande dificuldade das equipes de projetos. Destinar pouco tempo ao planejamento é um problema sério, pois não adianta executar um projeto sem minimamente ter uma noção, pelo menos superficial do escopo e dos riscos envolvidos. Mas mais grave ainda é destinar tempo demais ao planejamento, retardando em muito a execução e dando pouca margem ao empirismo. É importante encontrar um equilíbrio, evitando realizar um projeto sem traçar a estratégia necessária, nem sem demorar muito tempo para entregar algo de valor.

Seguem abaixo alguns pontos importantes para obter sucesso:

• Selecionar corretamente os membros chaves da equipe: É importante montar uma equipe com competências complementares.
• Desenvolver o comprometimento do time: Uma equipe motivada realiza até o impossível.
• Fazer estimativas realistas: Seja honesto com seu cliente, estime prazos e custos justos ao escopo do projeto.
• Se antecipar aos riscos: Prepare planos de ação e contingência para problemas que tem grande probabilidade de ocorrer.
• Não ter medo de Mudanças de Escopo: Não veja as Mudanças de Escopo como um problema! Alterações no escopo vão ocorrer, principalmente num projeto grande. O mundo muda, o negócio do cliente muda, os requisitos mudam, é natural o escopo mudar também.
• Priorizar o objetivo final: Ter foco nos objetivos, não nos entregáveis. Isso abre mais nossas possibilidades, nos faz pensar “fora da caixa”.
• Ter foco nos objetivos do cliente: Tenha foco no objetivo do cliente, não no produto. É para atender aos objetivos dele que você foi contratado.

Para alcançar boa parte desses objetivos, existem as áreas do conhecimento em Gerenciamento de Projetos, que são 9, ilustradas na figura abaixo:

No próximo post, vamos falar sobre Gestão do Escopo!

Até a próxima!

Conceitos de Gerenciamento de Projetos (Parte 2)

Já explicamos a diferença entre Projeto e Processo. Mas disso podemos fazer 2 perguntas:

1) O que é gerenciar um projeto?

Gerenciar um projeto nada mais é do que conduzi-lo unindo habilidades técnicas, interpessoais e administrativas.

A atividade de gerenciar um projeto deve atender às necessidades dos stakeholders, que são as pessoas envolvidas no projeto, e abrangem: cliente, equipe, fornecedores etc. Também devem atender ao escopo, prazo e custo, garantindo assim a qualidade.

2) Por que gerenciar projetos?

Há um certo preconceito contra metodologias de gerenciamento e padrões na condução de projetos. Porém, as atividades de gerenciamento nos permitem obter um melhor entendimento do projeto e de seus objetivos, no passo que estabelecemos o planejamento.

Uma vez definidos os objetivos do projeto, ferramentas de gerenciamento e planejamento auxiliam a definição do escopo e com isso o gerente pode adequar os trabalhos às necessidades do projeto.

Atividades de gerenciamento possibilitam um alinhamento da equipe com os objetivos do projeto, e por conseguinte, com os objetivos do cliente. Além de possibilitarem um maior controle do andamento do projeto, do desempenho dos membros da equipe, tudo utilizando métricas confeccionadas para a realidade do projeto.

Gerenciar projetos é uma questão organizacional. Cada gestor deve definir que metodologia e quais ferramentas utilizar para realizar da melhor forma possível a condução do projeto. Essa escolha depende da empresa, do tipo de serviço do projeto, do cliente, da equipe e obviamente da área de atuação do projeto, por exemplo, um projeto de TI provavelmente utilizará uma metodologia diferente de um projeto de Administração.

Um conceito muito importante que todo gerente de projeto deve ter é chamado Restrição Tripa. Trata-se de um triangulo muito famoso em livros da área de Gerenciamento de Projetos:

Na base da pirâmide, encontramos o escopo do projeto, que define o que será feito no projeto. No lado direito, o tempo, que deve atender aos prazos estabelecidos. No lado esquerdo, o custo. Falando de maneira geral, o custo é a reunião de todos os gastos (financeiros, materiais e humanos) que o projeto traz para sua realização.

O trabalho do gerente é garantir que essas 3 variáveis permaneçam bem balanceadas. Resumindo, deve garantir que os objetivos do projeto sejam alcançados de acordo com o escopo planejado, com um baixo custo e o mais rápido possível.

Perceba que cada variável afeta diretamente as outras. Por exemplo, se forem acrescentadas mais atividades não previstas no projeto, causando um aumento no escopo, o prazo fica comprometido e o custo deverá aumentar. O mesmo acontece se o tempo é reduzido, parte do escopo deve ser cortado, e provavelmente custos. E por aí vai.

Essa combinação entre o escopo atendido, prazos cumpridos e pouco custo, nos dará um projeto de qualidade. Porém, é muito difícil realizar essa ponderação de forma eficaz, por isso existe uma área de estudos muito grande em Gerenciamento de Projetos.

Nos próximos posts veremos um pouco mais sobre metodologias e boas práticas de gerenciamento de projetos. O objetivo desse post é apenas mostrar a importância do assunto.

Até a próxima!

Conceitos de Gerenciamento de Projetos (Parte 1)

Muita gente fala muito por aí sobre Gerenciamento de Projetos e muitas vezes sem nem saber o que está falando. Como esse é um assunto sempre atual, resolvi escrever uma série de posts explicando melhor alguns conceitos de Gerenciamento de Projetos que causam confusão para muita gente.
O primeiro conceito que gera confusão é a própria definição de Projeto.

• Projeto: É um esforço temporário com a finalidade de criar um produto ou serviço único.

Quando dizemos que um projeto é temporário, queremos dizer que ele tem início e fim bem determinados. Ou seja, com datas para início e prazo para o fim de suas atividades. Um trabalho que nunca termina ou não tem previsão de término não pode ser chamado de projeto.
Quando dizemos que um projeto gera um produto ou serviço único, estamos dizendo que um projeto não pode ser repetido. Se for repetido gerará um produto diferente, ou não será um projeto, passará a ser um processo.

Para testar se você entendeu bem esse conceito, responda a seguinte pergunta:

Você já gerenciou algum projeto?

A resposta será, provavelmente sim. A maioria das pessoas já gerenciou algum projeto. Até atividades simples e cotidianas podem entrar nessa definição. Por exemplo:

• Redação de um livro
• Construção de uma casa
• Realização de uma viagem
• Informatização de uma empres
• Lançamento de um novo produto

Veja se esses exemplos não se enquadram nessa definição.

Pois bem, agora que você entendeu o conceito de Projeto, ainda falta entender o que é um Processo.

• Processo: É uma atividade ou conjunto de atividades permanente e repetitivo, geralmente com resultado previsível.

Existem grande diferenças entre projeto e processo. O processo é um conjunto de atividades que ocorrem com uma determinada freqüência em uma organização. Por isso, quando as empresas realizam recrutamento e seleção de estagiários, funcionários e trainees, essa atividade é chamada de Processo Seletivo.
Para quem deseja aprender sobre Gerenciamento de Projetos, é fundamental entender esses dois conceitos e a diferença entre eles.
Processos geralmente são atividades administrativas ou que devem ser repetidas na organização para alcançar resultados previamente definidos ou manter ordem em um determinado setor. Podem envolver atividades de Marketing, RH, Financeiras, Qualidade ou outras.
Projetos geralmente são empreendimentos focados em um objetivo específico. Isso dará ao projeto a característica de único e temporário.
Muitas vezes, a implementação de uma determinada melhoria pode ser um projeto, mas que pode gerar um processo novo na empresa.
Processos podem ser mapeados e exigem um foco na disciplina em segui-los exatamente como foram preconcebidos. Projetos podem ser planejados e exigem um foco nos objetivos para os quais eles devem atender.

PMI Agile: Desenvolvimento Ágil com práticas do PMBoK?

Desenvolvimento Ágil com práticas do PMI? Será que isso é possível?

Bom, muito se fala atualmente sobre Desenvolvimento Ágil, principalmente na área de TI. Muitos fãs fervorosos de Agile e metodologias como Scrum e XP criticam ferozmente o arcabouço metodológico do PMI, entitulado como livro de “melhores práticas” ou Guide to the PMBoK.

Um dos principais argumentos contra o PMBoK é o fato de apresentar uma série de processos e ferramentas muito burocráticos para o desenvolvimento e gerenciamento de projetos, o que vai em contradição aos preceitos estabelecidos pelo Manifesto Ágil.

Porém, na minha opinião, aí está o maior equívoco. É importante lembrar que o PMBoK é um guia de melhores práticas. Ou seja, ele apenas sugere ferramentas de Gerenciamento de Projetos que já foram amplamente utilizadas e classificadas como “boas práticas”. Isso significa que não é obrigatório seguir todos os processos ou segui-los da forma exata como são apresentados. Portanto, o PMBoK não é uma metodologia, como muitos pensam, é apenas um conjunto de boas práticas.

Além disso, os projetos de TI têm características muito específicas e pouco comuns em projetos de outras áreas. Geralmente projetos de TI são muito suscetíveis a riscos, que variam desde problemas de comunicação com o cliente, mudanças de escopo e obviamente atrasos nos prazos até questões mais técnicas, como aqueles bugs inconvenientes que ninguém consegue identificar a causa.

Por esses e outros motivos, as metodologias ágeis encontraram grande aceitação no Universo de TI. Mas as metodologias ágeis não existem apenas para TI. Scrum por exemplo, surgiu na indústria automobilística. O guia do PMI, por sua vez é voltado para uma ampla classe de projetos, abrangendo todos os setores da economia. Por esse motivo, cada área e até mesmo cada empresa, deve criar sua própria metodologia de gerenciamento de projetos, escolhendo as ferramentas que mais se adequam a sua realidade. É isso que prega o PMI.

Tendo em vista esses conceitos, surgiu um grupo no PMI que visa aliar as metodologias ágeis ao Guia do PMBoK. O grupo chamado PMI Agile (Wiki: http://agile-pm.pbworks.com/ , Twitter: http://twitter.com/pmiagile ), estuda formas de aliar ferramentas utilizadas em metodologias ágeis, como TDD e Pair Programming ao arcabouço metodológico e generalista do PMBoK.

Sinceramente, eu gosto da idéia e espero que dê resultados.