A cada novo projeto de implantação, encontramos clientes que buscam uma forma de melhorar sua gestão por intermédio de boas práticas, metodologias e padrões de gerenciamento de projetos.

Já falamos aqui no blog sobre como preparar a sua empresa para a implantação de uma metodologia de gestão de projetos e listamos os 7 passos para você fazer isso com sucesso.

Nesse processo, muitas dúvidas surgem, tendo em vista a grande variedade de opções sobre padrões de gerenciamento de projetos e bibliografias existentes.

Para facilitar a vida de nossos clientes e leitores, que buscam implantar um padrão de gerenciamento de projetos, criamos um resumo das principais práticas.

Veja quais são as mais utilizadas e entenda o funcionamento delas a seguir. Boa leitura!

Project Management Body of Knowledge (PMBOK)

É um conjunto de conhecimentos gerenciado pela organização Project Management Institute (PMI), e tornou-se um padrão, de fato, em diversas indústrias. De maneira resumida, o PMBOK é visto como a mais importante bibliografia de gestão de projetos da atualidade.

Mais conhecido como “PMBOK Guide”, é de autoria do Standards Committee (Comitê de Padronização) do Project Management Institute – PMI e procura contemplar os principais aspectos que podem ser abordados no gerenciamento de um projeto genérico.

Não se trata de uma metodologia de gerenciamento de projetos e, sim, de uma padronização que identifica e nomeia processos, áreas de conhecimento, técnicas, regras e métodos. O guia foi reconhecido, em 1999, como um padrão de gerenciamento de projetos pelo ANSI – American National Standards Institute.

O PMBOK é um manual que descreve o universo de conhecimentos para o gerenciamento de projetos. Todavia, por sua imensa importância internacional, se transformou num padrão que é fonte de inspiração para quase todas as metodologias existentes.

Ele é um dos caminhos mais rápidos para quem deseja uma gestão altamente profissional e com ótimos resultados. Porém, é importante tomar cuidado com a flexibilidade deste elemento, que não é tão elevada. Se é necessário atender a questões muito específicas, o melhor é associar o PMBOK a alguma outra metodologia, de modo a balancear o gerenciamento.

Áreas de Conhecimento

Conforme padronização do PMI, os processos citados anteriormente abordam 10 áreas de conhecimento, que são:

1. Gerenciamento de Integração

2. Gerenciamento do Escopo

3. Gerenciamento do Tempo

4. Gerenciamento de Custos

5. Gerenciamento da Qualidade

6. Gerenciamento de Recursos Humanos

7. Gerenciamento de Comunicações

8. Gerenciamento de Riscos

9. Gerenciamento das Aquisições

10. Stakeholders (Nova área de conhecimento lançada na 5ª edição, com o objetivo de gerenciar melhor os stakeholders, identificando e endereçando suas necessidades para mantê-los engajados.

ISO 10006: 1997, Quality management – Guidelines to quality in project management

ISO 10006:2003, Quality management; Guidelines to quality in project management é um padrão internacional, desenvolvido pela ISO, específico para o gerenciamento de projetos.

A orientação na qualidade de processos, entre outros objetivos, busca assegurar que:

• as necessidades dos clientes sejam entendidas e entregues;

• as necessidades dos stakeholders sejam compreendidas e avaliadas;

• a política de qualidade seja incorporada à gerência da organização, tendo como norte os objetivos estratégicos e a busca de resultados, e que possa ser aplicada em projetos de complexidade variada.

A norma ISO 10006 aborda o gerenciamento de projetos, mas como a própria diz, não é um guia. Reúne diretrizes que devem ser usadas para manter a qualidade em projetos. Essas diretrizes, no entanto, podem ser adaptadas para um projeto particular.

Isso traz uma importante versatilidade, fazendo com que a possibilidade se encaixe em diferentes necessidades. Ao mesmo tempo, é preciso ter cuidado porque, como não funciona como um guia, exige uma estruturação complementar.

Para a ISO, um projeto deve ser realizado em um determinado espaço de tempo, enquanto o PMBOK enfoca a criação de um produto, serviço ou algo cujo resultado possa ser mensurável. A ISO 10006 aborda o processo que leva a este resultado.

A ISO fornece nove etapas para o processo estratégico:

• Foco no Cliente

• Liderança

• Envolvimento das Pessoas

• Aproximação dos Processos

• Sistema de Aproximação com a Gerência

• Melhoria Contínua

• Aproximação Casual para Tomada de Decisão

• Relacionamento Mutuamente Benéfico com Fornecedor

PRINCE2™: Projects IN a Controlled Environment

O PRINCE2™ é um método não proprietário para gerenciamento de projetos. É adaptável a qualquer tipo ou tamanho de projeto e cobre seu gerenciamento, controle e organização. Um projeto PRINCE2™ tem as seguintes características:

• Controle e organização do início ao fim;

• Revisão de progressos baseado nos planos e no business case;

• Pontos de decisão flexíveis;

• Gerenciamento efetivo de qualquer desvio do plano;

• Envolvimento da gerência e das partes interessadas em momentos-chave durante toda a execução do projeto;

• Bom canal de comunicação entre o time do projeto e o restante da organização.

O PRINCE2™ foi lançado como um método para gerenciamento de projetos pelo governo britânico em 1996. Foi criado em 1989 a partir do PROMPTII, o qual, por sua vez, surgiu em 1975 e foi adotado em 1979 como padrão para gerenciamento dos projetos de sistemas de informações governamentais.

Hoje, o PRINCE2™ é adotado como padrão para todos os projetos do governo britânico e amplamente utilizado pela iniciativa privada, não só no país, mas também em outros lugares como Europa, África, Oceania e Estados Unidos.

Considerado o método de gerenciamento de projetos mais utilizado no mundo, conta com mais de 250 mil profissionais certificados, sendo que, aproximadamente, 1.500 pessoas prestam, mensalmente, os exames de certificação Foundation e Practitioner.

Existem mais de 120 centros de treinamento credenciados PRINCE2™ pelo mundo, os quais proveem treinamento em 17 idiomas sobre as 59 ferramentas de gerenciamento de projetos desenvolvidas com base no método. No Brasil, a metodologia PRINCE2™ já vem sendo utilizada em algumas organizações, e é crescente a procura por informações a respeito do assunto.

IPMA: International Project Management Association

A International Project Management Association (IPMA®) é uma organização sem fins lucrativos, reconhecida por seu trabalho no desenvolvimento internacional da gestão por projetos, programas e portfólios, e na disseminação das melhores práticas aplicadas em organizações públicas e privadas.

A IPMA foi criada em 1965 com o nome de International Network INTERNET, a partir de um grupo de gestores de projetos que tinham como objetivo, nos primórdios da gestão de projetos, discutir os benefícios do Método do Caminho Crítico na gestão de projetos internacionais, com influências e dependências complexas de diferentes disciplinas técnicas.

A associação cresceu e desenvolveu-se como um fórum internacional de troca de experiências entre gestores de projetos. O primeiro congresso mundial foi realizado em Viena, Áustria, em 1967. O 26º em outubro de 2012 na Grécia e, em 2014, o Brasil receberá o 28º Congresso Mundial.

A IPMA é formada por associações nacionais de gestão de projetos. São mais de 50 associações de todo o mundo com o propósito específico de desenvolver a gestão de projetos, respeitando a cultura e as características de cada país, mas unidas através de uma rede que estabelece as diretrizes de gestão e técnicas para seu desenvolvimento e aperfeiçoamento.

Essa é uma maneira bastante adequada de conseguir gerenciar projetos que trabalham com uma pluralidade de culturas. Multinacionais que desejam implantar um mesmo projeto em diferentes áreas pode utilizar as boas práticas definidas pela organização para conseguir os melhores resultados específicos.

Scrum

O Scrum é um método ágil de desenvolvimento e gerenciamento de projetos, considerado o mais importante de sua categoria. Ele é muito bem aceito pelo mercado e pode ser aplicado em processos de diferentes tamanhos e setores.

Atualmente, é um modelo que faz todo o sentido devido à necessidade crescente de os processos serem melhores e mais eficientes, sem perda de tempo ou de recursos. Essa metodologia foi fundada em 1986 por uma dupla de profissionais japoneses. Não demorou muito até que ela se expandisse e evoluísse na forma como hoje é aplicada.

Para que a metodologia seja executada, o processo é dividido em ciclos temporais conhecidos como Sprints. Eles correspondem a um momento em que determinadas atividades devem ser executadas e, com base nisso, serem observadas para dar continuidade ao processo.

A partir da criação de um Sprint, há uma reunião com o principal interessado no projeto, definindo as prioridades de execução. A partir daí, devem ser feitas reuniões diárias — mas rápidas — de acompanhamento. A intenção é garantir que todos na equipe conheçam o andamento das tarefas para aquele Sprint, permitindo organização e atendimento às expectativas.

Uma vez que o Sprint seja finalizado, ele passa para a avaliação do product owner, que oferece feedback sobre o que deve ser modificado ou o que precisa ser feito no futuro. Isso ajuda a diminuir retrabalhos e favorece a identificação de erros.

Ao finalizar um Sprint, esse framework determina o recomeço das iterações, até que o projeto esteja inteiramente finalizado. No geral, é uma forma bastante eficaz de diminuir o tempo gasto na execução de tarefas, permitindo o aumento de capacidade da equipe.

Design Thinking

O Design Thinking é um conceito que surgiu em 2003, cunhado e divulgado pela empresa IDEO. O interesse principal dessa abordagem é buscar soluções para problemas antigos de maneira inovadora, alinhada e altamente integrada. Originalmente, ele servia para o design, propriamente dito, mas tornou-se uma forma consagrada de resolver problemas.

Como a gestão de projetos envolve imprevistos e um equilíbrio muito delicado entre diversos elementos, o Design Thinking surge como uma metodologia bastante útil para realizar todas as etapas conforme o esperado.

Para esse tipo de gestão, o Design Thinking surge como uma possibilidade ao permitir a entrada da criatividade, inovação e intuitividade nas etapas. Isso gera mais aproximação, integração e engajamento com essa questão, levando os projetos a um desenvolvimento mais adequado.

Ele é especialmente útil para projetos ligados à experiência humana, de modo a criar um resultado que seja condizente com as expectativas e necessidades do usuário. Porém, é importante compreender que não se trata de uma metodologia de gerenciamento de projetos e nem possui práticas definidas nesse sentido.

Com isso, ele não deve ser utilizado sozinho se a intenção é obter os melhores efeitos. Em vez disso, vale aplicar as técnicas de Design Thinking de maneira flexível e associada a uma metodologia considerada tradicional. O resultado é a diferenciação e o possível aumento do valor agregado.

Kanban

Para um projeto que visa à repetição de tarefas e ao incremento de resultados, o Kanban é uma boa metodologia a ser aplicada. Ele tem origem japonesa, na década de 60. A Toyota, que também foi a criadora dos processos Lean, começou a utilizar esse recurso altamente visual para aumentar a produtividade.

Basicamente, o Kanban ajuda na criação e na visualização dos fluxos de trabalho, favorecendo e ampliando a comunicação entre equipes.

Para que isso seja possível, o projeto é dividido em várias fases sequenciais e cada passo recebe um cartão. Conforme as tarefas forem sendo executadas, o cartão é movido para as etapas seguintes, até que tudo esteja na área de “concluído”.

Imagine, por exemplo, que um processo passa pela execução de quatro etapas diferentes. Nesse caso, o cartão deverá ser movido entre as quatro colunas, até que tudo esteja finalizado. Trata-se de uma forma de reconhecer, imediatamente, o que já foi feito e o que ainda precisa ser realizado.

Como a metodologia aprimora a comunicação, até mesmo por uma questão visual, a produtividade tende a ser elevada. Ao mesmo tempo, o melhor é que esse método esteja associado a práticas formais, como o PMBOK, de modo a garantir que cada etapa seja concluída conforme o desejado.

Independentemente da sua escolha, estar apoiado em uma metodologia de gerenciamento de projetos será decisivo para o sucesso dos seus projetos, sejam eles projetos pontuais ou até um grande plano, como um projeto de implantação de um PMO, por exemplo.

Para conseguir os melhores resultados, é importante ficar sempre atualizado. Por isso, nos acompanhe no Facebook, Twitter, LinkedIn, Google+ e Youtube para ter acesso a conteúdo de qualidade relacionado à temática de soluções de gerenciamento!

Compreender plenamente o projeto que está gerenciando é um fator determinante para obter o sucesso. Saber quem participa, seus objetivos, expectativas e interesses. Todas essas informações estão presentes nos documentos do projeto ou em seu software de controle de projetos. Mas e as informações que extrapolam a documentação? Conflitos políticos entre stakeholders? Líder técnico do projeto desmotivado? Cliente indeciso sobre os requisitos? Elementos como esses podem transformar o seu projeto em um verdadeiro mutante, que muda de forma a todo o momento, tornando complexo o seu gerenciamento.

Preparamos esse post com as principais perguntas que você deve fazer sobre cada projeto que está gerenciando. Eu imagino que você esteja pensando : “Thiago, estas perguntas são bastante básicas e o meu projeto muito complexo.” Realmente são perguntas básicas, mas o que mais me impressiona é que em muitos projetos elas não são respondidas, algumas vezes nem ao menos são feitas ou bem compreendidas. Aproveite e pergunte quando lhe for oferecido (ou na maioria das vezes exigido) um novo projeto. Se você já está em um projeto que não está indo tão bem, eu sugiro que se reúna com sua equipe e stakeholders para obter os esclarecimentos e respostas que você precisa para obter sucesso.

1. O que estamos fazendo?

Você já leu a proposta do projeto que está gerenciando e viu a declaração de escopo. Mas o que o projeto realmente está fazendo? Proposta de projeto e Declarações de Escopo raramente são claras o suficiente para saber o que os clientes querem fazer. Você está fazendo tudo o que você deveria estar fazendo? Você está fazendo coisas que deveria parar de fazer porque são além do escopo? Se você pode chegar a um acordo sobre essa definição, então você tem uma chance maior de está fazendo as coisas certas.

2. Será que os atores e membros da equipe do projeto compreendem o que estamos fazendo?

Será que todo mundo vê o projeto da mesma forma? Ou será que o projeto é como a Torre de Babel, onde cada um fala uma língua, baseados em suas próprias perspectivas. Alguns falam francês, alguns chinês e ninguém sabe exatamente sobre o que o outro está falando. Se assim for, pare. Coloque todos juntos em uma sala e faça uma sessão de trabalho para chegar a uma visão comum antes de fazer qualquer outra coisa. O nosso e-book “Guia Definitivo do Project Model Canvas” pode te ajudar nisso, pois o PM Canvas é uma metodologia que incentiva a colaboração e co-criação.

3. Por que estamos fazendo este projeto?

Qual é o verdadeiro objetivo do projeto e por que estamos investindo nosso tempo e recursos? Claro, nós queremos fazer um bom trabalho para o cliente. Mas há outras razões para o projeto? Por exemplo, é o projeto de importância estratégica para a nossa empresa, porque vai representar uma diferencial competitivo importante ou o projeto é importante porque a reputação e o ego de alguns executivos estão envolvidos? É possível quantificar as metas e compreender perfeitamente os requisitos?

4. Quem é o patrocinador e stakeholder mais influente no projeto?

Você já teve a experiência de trabalhar com ele antes ou conhece alguém que teve? Quanto melhor o seu relacionamento, acesso e comunicação com eles, mais fácil atingir o sucesso de projeto será. Além do patrocinador principal, certifique-se que você tem uma lista de todas as partes interessadas, por que eles estão envolvidos e quais são seus principais interesses, níveis de influências e se são protagonistas, antagonistas ou neutros. Alguns estão envolvidos, porque precisam ser mantidos informados, outros porque o projeto é essencial para a sua linha de negócios ou porque eles têm investido recursos e fundos nela. Neste caso, minha sugestão é que você construa uma Matriz RACI.

5. O que é mais importante para o patrocinador e stakeholder(s)? Qual é a sua meta prioritária? Apenas a construção do produto é o suficiente?

Basta entregar o serviço que fui contratado para fazer? A minha dica é que há sempre coisas mais importantes para o projeto do que apenas verificar se as entregas foram realizadas. Foque em ouvir e tentar captar a perspectivas deles.

6. Concordo que o cronograma do projeto é realista e viável?

Depois de entender o cronograma do projeto, como ele foi criado, e o que você está realmente fazendo, então analise friamente o cronograma e a conclusão prevista do projeto e responder a esta pergunta. Se ele não parecer realista ou viável, você só tem uma escolha: refazê-lo.

7. Como o projeto foi comunicada à equipe?

Isto pode parecer uma pergunta boba, mas gosto de perguntar porque com base em o que foi dito para cada membro da equipe na apresentação do projeto, pode fazer muita, muita diferença. Claro, você quer que todos da equipe tenham a mesma visão do projeto. Assim, como um primeiro passo (se você não tiver feito isso ainda), considere a criação de um PM Canvas que explique exatamente o que você está fazendo e por quê. Ele vai ajudar a manter todos informados e alinhados quanto a visão do projeto.

8. Como os membros da equipe foram selecionados para esse projeto?

As perguntas 8 e 9 estão relacionadas e são muito importantes. Você herdou a equipe? Se assim for, porque foram selecionados? Quem foi responsável por sua seleção e alocação no projeto? Como foram determinados seus papéis no projeto e suas atribuições? Em muitas empresas não é dedicada uma atenção especial para saber se cada recurso possui experiência e perfil para desempenhar a função atribuída em cada atividade. Eu sei que existe escassez da mão de obra e muitas vezes colocamos no projeto quem está disponível, mas dependendo da importância do projeto e sua complexidade, essa pergunta tem que ser muito bem respondida. Infelizmente existe um risco grande de que os membros da equipe foram designados simplesmente porque eles estavam disponíveis e não porque eram as pessoas certas para o trabalho.

9. Será que a equipe do projeto tem as habilidades que você precisa para ser bem sucedido?

Por último, o sucesso do projeto vai depender se você tem as habilidades certas na medida certa. Quais habilidades meu projeto demanda? Tenho membros da equipe com essas habilidades e no nível necessário? Onde somos mais fracos? Existe algum conhecimento não dominado pela equipe do projeto? Não é necessário que todos os membros da equipe sejam especialistas, mas é imprescindível ter um equilíbrio entre os conhecimentos necessários por cada atividade. Uma boa prática é realizar uma entrevista com cada pessoa da equipe e descobrir seus pontos fortes e fracos. Caso exista algo critico temos duas alternativas: buscar dentro da organização esse conhecimento ou tentar terceirizá-lo.

Então, quais são os fatores mais importante para a gestão de um projeto de sucesso? Compartilhe seus pensamentos em um comentário.

O Product Backlog é uma lista de funcionalidades desejadas de um produto, ou seja, os requisitos que um cliente espera receber ao final do projeto, descrito com sua própria linguagem. O ponto central do Scrum é a criação do Product Backlog, é nele que o projeto começa.

Diferente do modelo tradicional de gestão de projetos, onde precisamos fechar o escopo para poder começar a executar, no Scrum acredita-se que o início do projeto não é o melhor momento para isso. Afinal nesse ponto ainda não conhecemos suficiente o projeto e precisamos avançar um pouco mais em algumas hipóteses antes de ter tanta “certeza”.

Para te ajudar a combinar a gestão convencional com um framework mais ágil preparamos esse artigo onde descrevemos como fazemos aqui na Project Builder para criar nosso Product Backlog. Confira:

Uma mudança muito clara no mindset é que no início do projeto o Product Backlog não precisa estar completo. Podemos ter uma visão macro do produto e dos requisitos esperados. Conforme avançamos no projeto, o Product Backlog cresce e muda à medida que se aprende mais sobre o produto e seus usuários.

Para melhor estruturar o Product Backlog nós utilizamos as chamadas estórias — itens do Product Backlog — elas contém a descrição detalhada dos requisitos de cada solicitação a ser implementada. Em nossas estórias incluímos os seguintes campos:

ID

Uma identificação única, apenas um número com auto-incremento. O objetivo disto é evitar que, ao mudarmos seu nome, percamos o controle sobre as estórias.

Nome

Um nome curto e descritivo para a estória. Por exemplo; “Layout do Relatório”. O nome tem que ser explicativo o bastante, para que os membros do time e o Product Owner entendam minimamente sobre o que estamos falando, e específico o suficiente para distingui-la das demais estórias. Normalmente usamos de 2 a 10 palavras.

Importância

Definir qual é importância dessa estória na perspectiva do Product Owner (em relação ao cliente). Por exemplo: 10 ou 150. Quanto mais pontos mais importante.

Estimativa inicial

Estimativas preliminares que o time dá sobre quanto tempo será necessário para concluir uma determinada estória, se comparada as demais. Cada empresa trabalha sua estimativa de uma forma, mas normalmente dá-se uma pontuação que está diretamente relacionada à complexidade da tarefa e que servirá como base para se calcular quantos dias / horas / pessoas serão necessárias para entregar. Se a pontuação estiver muito alta, uma dica interessante é quebrar a tarefa em duas atividades, desta forma ficará mais fácil acertar na estimativa. A unidade está ligada a pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal. Faça a pergunta: Em X dias nós apresentaremos uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancadas em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória.

Como demonstrar

Em alto nível criamos uma descrição de como a estória será demonstrada na apresentação da sprint. É simplesmente uma especificação de teste. “Faça assim, então faça aquilo e, então, isso deverá acontecer.”

Notas

Quaisquer outras – breves – informações, esclarecimentos, referências a outras fontes de informação etc.

Aqui na Project Builder já tentamos outros campos, mas ao final do dia os seis campos citados acima eram os únicos realmente utilizamos Sprint após Sprint. Normalmente fazemos isso em um projeto no Project Builder, onde agrupamos em uma única fase todas as estórias do Product Backlog.

Oficialmente o Product Owner é o responsável pelo documento, mas nós não queremos deixar os outros usuários de fora. Várias vezes um desenvolvedor acessa a fase para esclarecer algo ou para alterar uma estimativa. Se você for utilizar o Excel, é importante que a planilha esteja compartilhada via Dropbox ou Google Docs.

Preparamos um exemplo de planilha que você pode baixar para utilizar na sua empresa.

Nos conte como está seu Product Backlog.

Quem já trabalha com o Gráfico de Gantt ou ao menos ouviu falar sobre essa ferramenta de gestão não imagina o quanto ela já foi útil ao longo da história. Dos idos de 1890 até os dias atuais, esse recurso vem sendo usado para ajudar a planejar, controlar e analisar atividades e processos nos mais diversos segmentos, entre eles, o gerenciamento de projetos.

Para fazer jus à importância do Gráfico de Gantt na história, resolvemos ir em busca de informações que ajudem a compreender o surgimento dessa ferramenta e o que ela representa. E sabe o que descobrimos? Vai saber ao ler este post! Pronto então para uma verdadeira viagem no tempo?

Quem foi Henry Laurence Gantt?

Engenheiro mecânico e consultor de empresas em processos industriais e de gestão, Henry Gantt (1861-1919) nasceu em Maryland, nos Estados Unidos. Sua principal atuação como consultor de empresas se baseava na otimização de processos para o aumento da produtividade e da eficiência nas linhas de produção. Por essas e outras, sua carreira profissional o levou a trabalhar juntamente com Frederick Taylor, considerado o pai da administração científica.

Qual a história do Diagrama de Gantt?

A primeira versão da ferramenta foi desenvolvida pelo engenheiro polonês Karol Adamiecki, em 1890. Contudo, após algumas adaptações que a tornaram mais clara e de fácil compreensão, Henry Gantt a lançou para o mundo em 1903, implementando-a na indústria como forma de planejar, organizar e controlar a produção.

Com a ajuda do Diagrama passou a ser possível planejar em detalhes a linha de produção, distribuindo adequadamente as atividades ao longo das horas de trabalho de cada funcionário, o que ajudava a prever o volume de peças por colaborador e por dia, garantindo, assim, que os pedidos dos clientes fossem atendidos dentro do prazo estabelecido.

A partir desse controle bem mais próximo da linha de produção, as indústrias também puderam otimizar seus estoques de modo a manter a atividade dos operários constante, mas sem excesso de insumos dentro da fábrica, o que levou a uma maior rentabilidade para os negócios.

Primeira Guerra Mundial

Como você deve se lembrar, os Estados Unidos entraram tardiamente na Primeira Guerra Mundial. E um dos fatores que fizeram com que essa demora ocorresse foi o despreparo das forças armadas americanas para entrar em combate, uma vez que eles não enfrentavam disputas havia mais de 50 anos.

Foi então que o General William Crozier, chefe da Portaria para o Exército dos Estados Unidos, convidou Henry Gantt para ajudar no preparo dos soldados para a empreitada prestes a ter início. O Gráfico de Gantt foi usado, então, para planejar as atividades de produção industrial de armamentos, munições e veículos de guerra, entre outros.

Grande Depressão

A crise de 1929, também chamada de A Grande Depressão, colocou os Estados Unidos em sérias dificuldades econômicas, o que se estendeu até a Segunda Guerra Mundial. A solução encontrada pelo governo americano para estimular a economia e voltar a crescer foi o famoso New Deal, um conjunto de políticas econômicas traçado pelo então presidente Franklyn Delano Roosevelt.

Um dos grandes feitos dessa manobra econômica foi a construção da represa Black Canyon, no Colorado. Devido à grandiosidade da obra, foi preciso adotar uma ferramenta que ajudasse a monitorar seu prazo de desenvolvimento, bem como coordenar as atividades dos mais de 20 mil trabalhadores ali alocados. A ferramenta adotada foi, claro, o Gráfico de Gantt, que não só ajudou a planejar e controlar o cronograma do projeto, como foi um dos responsáveis pelo sucesso da empreitada.

Declínio

Foi na Segunda Guerra Mundial que os primeiros computadores passaram a ser usados como ferramentas de análise preditiva, dispensando outros recursos que vinham sendo bastante empregados — como o Gráfico de Gantt. Até então, o diagrama era feito no papel, o que exigia retrabalhos a cada alteração da estratégia. Como os exércitos não tinham tempo para manter esse documento atualizado, acabaram por dispensá-lo de seu dia a dia. Mas esse não era o fim.

Gerenciamento de projetos

Em meados de 1960, o Gráfico de Gantt voltou a ser usado, mas dessa vez não exatamente na indústria, mas em um mercado totalmente novo, que ainda apenas engatinhava: o gerenciamento de projetos. Como se trata de uma ferramenta bastante visual e de fácil compreensão, o diagrama passou a ser usado para ajudar a determinar o caminho crítico de projetos.

Com a ajuda do Gráfico de Gantt, os gerentes de projetos podiam identificar com precisão tanto o início como o término de cada atividade, assim como as folgas, os gargalos, as interdependências e o progresso das atividades, de forma a tomarem decisões mais assertivas em relação à execução dos projetos desenvolvidos.

Essa finalidade do Gráfico de Gantt é usada ainda hoje e se mostra bastante eficiente. Contudo, como o acesso à tecnologia revolucionou o mundo, passou a ser possível apenas lançar os dados em um software de gerenciamento de projetos e extrair o Gráfico de Gantt em forma de relatório.

Como montar seu Gráfico de Gantt?

O Gráfico de Gantt é baseado em uma linha do tempo em que o eixo horizontal representa as horas, os dias ou as semanas e o eixo vertical exibe as atividades. Marca-se o início e o fim de cada atividade, criando uma linha dentro do gráfico. Se preferir, você pode determinar cores diferentes para as atividade, agrupando-as conforme sua necessidade e, assim, tornando o gráfico ainda mais visual.

Depois de listadas todas as atividades e suas durações, você pode incrementar o Gráfico de Gantt com os nomes dos responsáveis por cada tarefa ou ainda reorganizar as atividades de modo que as interdependências fiquem mais evidentes. É possível ainda sinalizar o progresso da equipe, alterando a cor dos trabalhos já concluídos ou dos que estão em atraso, dando maior destaque ao que deve ser feito na sequência.

Ah, e não se esqueça de deixar seu Gráfico de Gantt à vista de toda a equipe, para que todos os membros possam visualizar o desenvolvimento do projeto e verificar suas responsabilidades sempre que for preciso. Se quiser se aprofundar mais no uso desse recurso no gerenciamento de projetos, sugerimos que leia este post!

Agora nos conte: você já conhecia a história do Gráfico de Gantt? Já teve a oportunidade de usar essa ferramenta em seus projetos? Comente aqui e nos conte sua experiência!