Projetizando a Vida

Quando se fala sobre Projetos, estamos falando de um empreendimento temporário, que visa a produção de um produto único.

Hora, se vamos Gerenciar um Projeto, o que vamos fazer?

Vamos controlar e qeuilibrar 3 grandes variáveis:

Escopo

São as exigências especificadas para o resultado fim, ou seja, o que se o produto a ser produzido. Isso deve ser extremamente bem detalhado, para evitar problemas, por exemplo, Produzir um Carro. Ele precisa ter carroceria, rodas, motor, acabamento. Apenas isso? Não, o motor tem infinitas peças,   O Acabamento muito mais, e os itens de segurança, e… enfim, muita coisa.
E é preciso ter um cuidado de controlar os detalhes, principalmente quando várias pessoas estão trabalhando, tem muita gente que quer fazer “Melhor do que foi pedido”e isso pode (e normalmente é) um desastre.
Imagine o seguinte, o cara que vai fazer os faróis acha que ao invés de fazer o farol com determinado desenho pode fazer algo melhor, mais bonito, que aproveite melhor a luz, melhorando a segurança… O único problema é que não vai encaixar na carroceria, mas que ficou mais bonito ficou…
Parece piada, mas que já usou fábrica de software em projetos de TI sabe o que estou dizendo…

Tempo

Se o projeto é temporário, tem um tempo para ser executado e atrasar o projeto é algo normal,e muitas vezes o resultado é uma calamidade.
Um exemplo: Seu projeto é montar uma vitrine para uma loja de presentes par ao natal. Você monta uma vitrine fantástica, a melhor do mundo, ninguém vai olha r para ela e resistir a comprar o que está lá. Sucesso? Depende, se ficou pronta no dia 26/12…

Custo

Esse é um dos principais problemas do Gernete de Projeto, pois raramente temos condições de negociar muito isso, principalmente em emrpesas que vendem o projeto ao cliente sem consultar o Gerente de Projetos, ou quando somos contratados para tocar um projeto já iniciado…
Pior ainda só aqueles projetos em que  dizem: RECURSOS ILIMITADOS, o que você precisar, você terá…
Sobre isso, si tenho uma coisa a dizer, uma dica infalível: É MENTIRA !

Vamos pensar em alaguem que tem recursos ilimitados, o melhor Gerente de Projetos que existe, com capacidade de fazer um projeto monstruoso gigantesco num tempo extremamente…
Sabem quem é esse Gerente? Não? Vou dar uma dica: O prazo eram 7 dias…

Provavelmente já sabe, mas vou pedir desculpas aos Ateus e aos Evolucionistas (eu sou evolucionista) e usar a teoria do Criacionismo para explicar.
Estou falando de Deus, onisciente, onipresente e onipotente (3 características que facilitariam muito a vida de um Gerente de projeto).
Em apenas 7 dias, na verdade 6, pois como o cronograma adiantou, ele descansou no sétimo (novamente mais um sonho dos Gerentes de Projeto).
Mesmo com todos os recursos, ele precisou improvisar (a mulher precisou ser feita de uma costela…).
E com todos esse poder, com todos esses recursos, ele não conseguiu convencer todo mundo, afinal, existem muitos Ateus e Agnósticos no mundo…

Obviamente você não é Deus (se for e estiver lendo meu blog, deixa um comentário e divulgue o blog em sua “esfera de influência, eu agradeço antecipadamente…), por isso, seus recursos são limitados sim, por maiores que eles sejam…

Alguns autores falam numa quarta variável A QUALIDADE.

Eu sigo alinha de que não existe uma variável qualidade, pois qualidade não é variável, é algo binário SIM ou NÃO: ou tem ou não tem.

QUALIDADE é atender as expectativas, e quais são as expectativas que um Geente de Projetos tem que atender?

Entregar o produto como foi solicitado(Escopo) no Prazo acordado(Tempo) com o Orçamento (Custo) previsto.

Ou seja: Qualidade é obrigação e não Variável.

Essas 3 variáveis formam o “Triangulo de Ferro”do Gerenciamento de Projetos, e cuidado, é IMPOSSÍVEL mexer em um dos lados do Triangulo sem mexer em PELO MENOS um dos outros dois, muitas vezes sem mexer  NOS DOIS.

Um Exemplo:

Seu projeto é cavar um posso de 1 metro de diâmetro, 3 metros de profundidade em uma semana e tem 2 homens (custo = salário dos dois homens).

E Ai você tem as solicitações:

• 1. Dá pra fazer um poço de 6 metros? Dá sim, se eu tiver 2 semanas ou 4 homens.
• 2. Dá Pra fazer em meia semana? Dá, se eu tiver 4 homens ou fizer um poço de 1 metro e meio
• 3. Dá pra eu fazer com um homem só? Dá, se eu tiver 2 semanas ou fizer um poço de 1 metro e meio

Mas CUIDADO.

Essas alterações nem sempre são lineares, imaginem 4 homens trabalhando num buraco previsto para 2. Pode haver perda de produtividade, e ai, novamente, mexe nas variáveis.

Voltarei a falar do assunto num artigo sobre CRONOGRAMAS.

LEia mais no Blog Reflexões Digitais

Todo mundo que já gerenciou ou mesmo já participou de alguns projetos deve ter ouvido, ou até mesmo dito essa frase,d e maneira mais ou menos educada…

Existe uma estatística do PMI que diz que 80% dos projetos não terminam no prazo, com o custo estimado ou com as características prometidas, isso quando não acontece as 3 coisas, ou seja, em maior ou menos escala 80% dos projetos dão M….

Quando falo siso não estou falando de projetos públicos, que muitas vezes nascem já se sabendo que vai estourar a verba, nem de projetos gigantescos com inúmeras variáveis, falo de projetos no sentido mais amplo…

O PMBOK, as metodologia de gerenciamento e até este blog se propõe a auxiliar para que esse percentual de falhas.

Muita gente usa a palavra fracasso, eu não gosto de usá-la, pois fracasso é algo definitivo, já falha é algo corriqueiro e contornável, QUASE sempre é possível recolocar o projeto nos trilhos, e isso depende, fundamentalmente, do Gerente de Projetos.

Mas o que um Gerente de Projetos PODE e PRECISA fazer, quando um Projeto dá M…. ?

O Que PODE ser feito Depende de alguns fatores, como Bom Sendo, Domínio da situação, Autonomia e Coragem.

A Autonomia de um GP depende do tipo de organização em que ele trabalha, mesmo num projeto pessoal, como seu Projeto de Vida, existe uma organização envolvida, a Organização Familiar, um GP solteiro que não tem ninguém que dependa dele tem autonomia maior, ou quase total , já quando se tem dependentes, sejam esposa(o), filhos, pais ou agregados, a autonomia não é tão grande.

Domínio da situação também é fundamental, e nem sempre depende do GP, entra ai o Bom Sendo, para definir tudo isso.

E finalmente a Coragem, muitas vezes você precisa dar a cara pra bater, assumir o erro e isso nunca é fácil.

Agora, o que o Gerente de Projetos PRECISA fazer?

A Primeira atitude do Gerente de Projetos é identificar o problema, quanto antes o Problema for detectado, menos o custo para corrigi-lo.

A Primeira coisa é admitir para SI MESMO que alguma coisa está errada, e esse é um dos passos mais difíceis.

Identificado o problema é preciso avaliar o impacto no resultado final do projeto.

Avaliado o Impacto é preciso determinar os caminhos a seguir, normalmente existe mais do que um, se você só vê um caminho CUIDADO, se não existe decisão a ser tomada, provavelmente não é necessário um Gerente de Projetos…

Uma possibilidade que muita gente ignora é a de deixar rolar.

Determinadas as soluções possíveis, é preciso uma análise de Custo X Benefício: Qual é o custo (em termos de esforço, prazo, imagem, credibilidade, etc.) de cada uma delas, inclusive de deixar rolar.

Com essa análise feita entra a CORAGEM, ou seja escolher a melhor opção PARA O PROJETO, e na para o Gerente.

Resta agora replanejar tudo, e aqui é preciso cuidado. Um replanejamento em um projeto é normal, dois é aceitável, três é crítico…

Mas existe projetos com MUITOS replanejamentos, isso demonstra falta de planejamento, falta de Experiência, de bom Sendo ou de Coragem.

Existem projetos que não simplesmente não são possíveis de serem executados, é verdade, mas isso só demonstra falta de Bom Senso, deveria ser quebrado em atividades menores e cada uma ser tratada como um projeto a parte.

Quando falo em Coragem é a coragem de assumir que a nova data final é inatingível, o que via causar novo replanejamento, o que deve ser feito é pensar numa data REALISTA e defendê-la “até a morte”.

Um “detalhe” importante é determinar com muito cuidado as causas do problema, para evitar que os erros se repitam.

Mas vamos a um exemplo prático, uma M…. real!

Como falei no artigo sobre planejamento, 90% dos problemas de projeto se devem a erros de planejamento, e o erro mais comum é desprezarmos “fatores externos”…

Quando comecei meu projeto de escrever uma série de artigos sobre Grupo de Processos no PMBOK me comprometi com um cronograma de 2 artigos por semana, ignorando fatores externos como meu emprego que me consome 10 H/dia, meus outros blogs (Blog Profissional e Boteco Futebol), alguns clientes blogueiros e minha família…

Resultado: Cronograma comprometido. Precisei fazer na semana passada um primeiro Re-Planejamento, e sem avaliar corretamente o problema, me comprometi a “retirar o atraso”…

Na maioria dos projetos quando assumimos essa retirada de atraso, aproveita-se algo que já tem, com pequenas adaptações e deixa-se de fazer atividades “desnecessárias”, como testes e controle de qualidade (Alguem já viu isso acontecer?).

Resultado uma grande M…..!

Nesse caso aproveitei alguns artigos antigos e “cumpri o cronograma”, só que meu “controle de qualidade” deixou passar um detalhe, o artigo era baseado no PMBOK 2000 e não no PMBOK 2004 !!!!!

Resultado, novo replanejamento, dessa vez com maior cuidado, correção do problema (O Grupo planejamento foi re-escrito e o de Execução foi “retirado para revisão”).

Depois disso estabeleci um novo cronograma, agora levando em conta atividades “extra-projeto” e publicarei UM ARTIGO POR SEMANA dessa série, a começar pela revisão do Grupo de Execução que ocorrerá até sexta-feira.

Bom que isso sirva de exemplo a todos, mesmo Gerentes de Projeto com experiência costumam errar, principalmente em projetos onde o “Cliente” não é muito exigente…

Anote isso no seu caderninho de lições aprendidas, pois como falei no artigo sobre planejamento: Shits happen !!!

TEXTO REVISADO.

Este artigo é parte de uma série de 5 artigos que apresentam os 5 Grupos de processo de Gerenciamento de Projetos descritos no PMBOK:

1. Iniciação - Define e autoriza o projeto ou uma fase do projeto..
2. Planejamento - Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.
3. Execução. Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.
4. Monitoramento e controle. Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.
5. Encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

O Terceiro artigo falaremos sobre Execução

O Grupo de processos de execução é composto pelos processos que tem por objetivo coordenar pessoas e outros recursos para realizar o plano do projeto gerado pelo grupo de processos de Planejamento.

Segundo informações que obtive (não tive acesso ao documento oficial ainda) no Draft da nova versão do PMBOK, versão 4 a ser lançada (espera-se) ainda em 2008 o Grupo de processos de execução está deixando de existir, sendo que os processos pertinentes estão sendo migrados para o Grupo de Processos de Monitoramento e Controle. Espero o lançamento oficial do PMOK 2008 para confirmar isso, mas gostei da novidade, uma das coisas com que nunca concordei plenamente com o PMBOK é existir esse grupo, pois a função do Gerente de Projetos é fazer com que o projeto ocorra conforme planejado,e não executá-lo. Quando ele faz isso (no caso, por exemplo, de um projeto de vida) ele deve usar “dois bonés”, o do executor e o do Gerente, como só tem uma cabeça deve usar um boné de cada vez.

Mas, como ainda falamos da versão 3 (ou 2004), existe esse grupo de processos, composto dos seguintes processos:

1. Orientar e gerenciar a execução do projeto

Anteriormente chamadod e Executar plano do projeto este processo visa garantir que o plano seja executado e que APENAS as atividades definidas no plano serão executadas. É comum gerentes iniciantes executarem atividades adicionais, para “agradar o cliente”. Ë claro que você pode agradar o cliente, mas no primeiro atraso gerado, ele esquece disso, e vai te cobrar. Conhece a história do Plantador de Arroz? Conto num outro artigo, em breve (afinal meu plano de projeto para o projeto de série sobre os grupos de processo não prevê essa atividade…*rs) . Esse é o único processo essencial, os demais são Processos facilitadores.

3. Realizar a garantia da qualidade

Eu não concordo com pessoas que dizem que um produto tem mais ou menos qualidade. Para mim qualidade é binário, ou sim ou não, ou tem qualidade ou não tem qualidade, isso porque qualidade é atender expectativas, portanto ou atende ou não atende (essa história de “atende parcialmente” é igual “parcialmente grávida”) Usa-se muito qualidade superior e qualidade inferior, isso define uma categoria, não a qualidade em si. Esse processo consiste em avaliar regularmente o desempenho geral do projeto, com o objetivo de satisfazer os padrões estabelecidos de qualidade (em outras palavras atender a expectativa).

3. Contratar ou mobilizar a equipe do projeto

Projetos são executados por pessoas (por enquanto, afinal, ainda não existem robots inteligentes), portanto por uma equipe (nem que seja uma equipe de uma única pessoa. No início desse projeto a pessoa pode “existir” ou não. Se existir voce precisa mobilizá-la, ou seja colocá-la em condições de trabalhar, isso envolve atribuir as atividades, fornecer as condições básicas e etc. Caso a pessoas não “exista”, é preciso contratá-la, antes de mobilizá-la.

4. Desenvolvimento da Equipe

É comum em projetos precisarmos de pessoas que assobiem e chupem cana, sem desafinar e ainda sirvam cafezinho…

Nem sempre as pessoas que dispomos ou conseguimos contratar, tem todas as habilidades necessárias, é portanto necessário desenvolver a equipe,  ou seja, trabalhar o grupo para que as habilidades necessárias estejam presentes.
Sem isso, o projeto terá um desempenho deficiente.

5. Distribuição das Informações

Olha a comunicação ai geeeeeeeeeente!!! Já dizia o maior comunicador desse país, Abelardo Barbosa, o chacrinha: “Quem não se comunica se estrumbica”. Comunicar não é apenas falar, enviar a mensagem. Ë enviar a mensagem e garantir que isso seja entendido por todos os “Stakeholders”, não apenas os membros da equipe. Voltarei a falar sobre isso em um artigo futuro sobre Comunicação e Stakeholder.

6. Solicitar respostas de fornecedores

Em outras palavras solicitar propostas, informações, cotações, licitações, enfim, tudo aquilo que voce precia para  comprar algo, se precisar comprar algo, é claro.

7. Selecionar de Fornecedores

Você já comprou algo no Mercado Livre de um vendedor com 0(ZERO) referencias? Por mais honesto que ele seja, e mesmo sendo o Mercado Livre e a maior parte dos vendedores idôneos, o numero de vendas e o percentual de satisfação garantem a entrega e a satisfação (a SuperLoja do Jobson só mostra produtos desses clientes, por isso estou criando uma…*rs). o mesmo cuidado ao comprar algo para seu projeto, principalmente se precisar de ume entrega programada, as vezes é melhor pagar mais caro do que ter o projeto paralisado por não receber o produto adequado de um fornecedor desconhecido.

OBS: É sempre bom alertar que esses processos são as MELHORES PRÁTICAS, nem todos são executados em todos os projetos. Novamente o PMBOK não é uma metodologia a ser seguida a risca, é “apenas” um guia de “conselhos”.

Alguns desses processos precisam ser melhor detalhados, e serão em artigos futuros.

Este artigo é parte de uma série de 5 artigos que apresentam os 5 Grupos de processo de Gerenciamento de Projetos descritos no PMBOK:

 1. Iniciação - Define e autoriza o projeto ou uma fase do projeto..
2. Planejamento - Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.
3. Execução - Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.
4. Monitoramento e controle. Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.
5. Encerramento. Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

O Segundo artigo falaremos sobre PLANEJAMENTO.

Ouvi uma vez de um Gerente de Projetos uma frase que é das mais verdadeiras relativa a Gerenciamento de Projetos e que tomo por lema é: “90% dos problemas de projeto, para ser conservador, poderiam ser evitados se tivéssemos feito um bom Planejamento em seu início”.

 Muitos podem contrariar essa frase dizendo que imprevistos acontecem, que a lei de Murphy é implacável, ou como diriam os americanos em seu pragmatismo: “shits happen”…

 Sim isso é verdade, acontecem mesmo, e com muita freqüência e é exatamente por isso que existe o planejamento, evitar que as shits aconteçam ou, pelo menos, ter uma resposta adequada quando acontecerem. Em outras palavras, a maioria dos imprevistos são previsíveis, e pode portanto ser controlados.

 Já vi muito gerente de projeto iniciante dizendo, em listas de discussão : “Oi pessoal, estou começando a gerenciar um projeto e preciso de um ‘template’ de um Plano de Projeto, alguém pode me dizer onde baixar um ‘di-gratis’…”, como eu gosto de citações (mania de palestrante), costumo responder com apenas uma frase do Dwight D. Eisenhower (34º presidente dos EUA) : “Um plano não é nada, Planejar é tudo…”

Falar é fácil, eu tinha prometido escrever 2 artigos por semana sobre os Grupos de Processo do PMBOK, e na primeira semana, furei, escrevi apenas um… Pois é Shits happen…

Tive um problema de saúde, fiquei de cama na sexta, enfim, aconteceu um imprevisto, que poderia se previsto,a final todo mundo pode ficar doente, todo mundo pode sofrer um acidente, etc, etc…

 Eu poderia ter previsto isso e ter escrito um artigo “de reserva”, assim, poderia simplesmente publicar e hoje estaria escrevendo o terceiro e não o segundo, como não fiz me resta REPLANEJAR: ou eu altero meu cronograma, atrasando a conclusão da série ou escrever 3 artigos essa semana e assim, cumprir o prazo final. É o que farei.

 Só pra concluir o “prolegômeno”(adoro palavras difíceis…), sei que vão dizer, depois que acontece é fácil falar… Sim, realmente é, por isso recomenda-se que todo Gerente de Projetos tenha seu “caderninho” “lições aprendidas”, isso é uma entrada a mais no seu planejamento futuro, e assim as “shits” só acontecem uma vez…

Bom, mas vamos ao que interessa: PMBOK - Grupo de processos - Planejamento.

 Para muita gente Planejar um projeto é criar um cronograma, funciona assim, você pega um template do MS-project, “chuta” quanto tempo gata para executar aquelas atividades que estão lá, coloca uma margem de segurança de 20 a 50%,e pronto, é só sair executando…

 Se você planeja assim, um treinamento para ficar perfeito: Vá para a frente do espelho e comece a treinar o sotaque: shits happen, shits happen, shits happen. Isso tem que soar perfeito e natural quando você for expor o resultado do projeto.

 Não sou maluco de dizer que o cronograma é inútil, um cronograma bem feito, uma boa planilha de riscos (falarei sobre riscos num artigo futuro) e uma dose cavalar de bom senso podem ser, muitas vezes, o suficiente para que o projeto tenha sucesso, mas o Cronograma e a Planilha de riscos são resultados do Planejamento,e não o planejamento em si.

 O Grupo de processos Planejamento, do PMBOK contem os seguintes processos:

1 Desenvolver o plano de gerenciamento do projeto

O Objetivo deste processo é definir, preparar, integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto.  

2 Planejamento do escopo

O Objetivo deste processo é criar um plano de gerenciamento do escopo do projeto. Nele documenta-se como o escopo do projeto será definido, verificado e controlado e como a estrutura analítica do projeto (ou WBS – Work Breakdown Struture)  será criada e definida.

3 Definição do escopo

O Objetivo deste processo é gerar uma declaração do escopo detalhada do projeto. É um processo fundamental porque é muito comum recebermos demanda como Criar um relatório XYZ. E quando vai criar você verifica que as informações não existem, ai entra o JAQUES está fazendo o relatório, aproveita e faz uma tela para entrada de dados… JAQUES ta fazendo essa tela, faz a critica de validade… E por ai vai. Por isso : Detalhe o escopo. Parece a mesma coisa mas não é. Item o “cliente” pede, o item 2, o Gerente de Projetos diz o que precisa fazer para atender o item 1.

4 Criar EAP (ou WBS)

O Objetivo deste processo é subdividir as principais entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.

5 Definição da atividade

Esse é fácil, o que eu preciso fazer para produzir o escopo desejado… (fácil de entender, de fazer, nem sempre…)

6 Seqüenciamento de atividades

Em que seqüência as atividades precisam ou podem ser executadas, quem depende de quem?

7 Estimativa de recursos da atividade

Qual o esforço que você precisa para fazer cada uma das atividades?

8 Estimativa de duração da atividade

Qual o tempo que você gasta para executar essa atividade com os recursos disponíveis.(ou pode acontecer o contrário, termos uma prazo fixo e variamos os  recursos)

9 Desenvolvimento do cronograma

Deenvovler  o cronograma do projeto a partir da análise das atividades, da seqüência das atividades, suas durações, e as necessidades de recursos (em outras palavras,  de forma muuuuuito simplificada pega-se os itens 5, 6, 7 e 8  e coloca no Project).

10 Estimativa de custos

Aqui é que pega, quanto Custa???

11 Orçamentação

Detalhar o item anterior, ou seja COMO e QUANDO você vai gastar o orçamento.

12 Planejamento da qualidade

O Objetivo deste processo é identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los.

13 Planejamento de recursos humanos (montagem da equipe)

Conseguir que os recursos humanos necessários sejam designados e alocados ao projeto. Isso é complicado quando precisamos de profissionais de outras equipes, ou mesmo de outras empresas. ( O gestor quase nunca está disponível…).

14 Planejamento das comunicações

Estima-se que 90% do trabalho de um Gerente de Projeto, mesmo assim ATÉ o PMBOK relega essa atividade a um nível inferior, dedicando, na terceira edição) apenas 14 páginas de suas 405 ao assunto, ou seja meros 3,5%.

15 Planejamento do gerenciamento de riscos

O Objetivo deste processo é decidir como abordar, planejar e executar as atividades de gerenciamento de riscos de um projeto.

16 Identificação de riscos

Riscos são eventos que podem alterar, para melhor ou para pior (Oportunidade ou Ameaça), a chance de sucesso do projeto. Este processo consiste em identificar esse prováveis eventos.

17 Análise qualitativa de riscos

Uma vez identificados os riscos, este processo visa priorizar riscos para análise ou ação adicional subseqüente através de avaliação e combinação de sua probabilidade de ocorrência e impacto.

18 Análise quantitativa de riscos

O Objetivo deste processo é analisar numericamente o efeito dos riscos identificados nos objetivos gerais do projeto.

19 Planejamento de respostas a riscos

O Objetivo desse processo é avaliar os processos 16, 17 e 18 para desenvolver opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

20 Planejar compras e aquisições

Este é o processo necessário para determinar o que comprar ou adquirir e quando e como fazer isso.

21 Planejar contratações

Este é o processo necessário para documentar os requisitos de produtos, serviços e resultados e identificar possíveis fornecedores.

Como da pra ver são várias atividades alem de simplesmente montar um cronograma, mas como fazer isso?

O PMBOK não é uma metodologia, embora muitas empresas de treinamento vendam cursos sobre a “metodologia PMI”, a metodologia é o método que VOCÊ ou SUA EMPRESA usam para implementar esses processos.

Num próximo artigo vou apresentar UMA forma de planejamento que eu gosto (nem sempre é possível) usar.

PS. A figura acima é um diagrama de um Mapa Mental (MindMap), um diagrama usado numa técnica de planejamento que gosto muito. Voltareia falar no assunto e explicar seu funcionamento no futuro.

Este artigo é parte de uma série de 5 artigos que apresentam os 5 Grupos de processo de Gerenciamento de Projetos descritos no PMBOK:

1. Iniciação - Define e autoriza o projeto ou uma fase do projeto..

2. Planejamento - Define e refina os objetivos e planeja a ação necessária para alcançar os objetivos e o escopo para os quais o projeto foi realizado.

3. Execução -  Integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto.

4. Monitoramento e controle - Mede e monitora regularmente o progresso para identificar variações em relação ao plano de gerenciamento do projeto, de forma que possam ser tomadas ações corretivas quando necessário para atender aos objetivos do projeto.

5. Encerramento -  Formaliza a aceitação do produto, serviço ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Neste primeiro artigo falarei do Grupo de Processos de Iniciação.

Quando recebemos a demanda de um projeto, principalmente quando somos pressionados pelo tempo (o que NORMALMENTE OCORRE), somos tentados e Iniciar o mais rápido possível, sem pensar muito, sem planejar, um verdadeiro “fazejamento”…

Depois de dois ou três projetos feitos na marra, as vezes até conseguindo relativo sucesso, começa-se a sentir a necessidade real do Planejamento, mas ainda assim, se não somos cobrados, esquecemos da Iniciação…

Isso me lembra uma história de São Pedro (Gerente de Projetos do Céu), chegou um senhor, já de idade,q eu tinha morrido com uma pancada na cabeça, que lhe causou amnésia, São Pedro perguntou pra ele:

Qual seu Nome ? O Sr. Respondeu: Não sei, eu tenho amnésia…

São Pedro, GP experiente, tentou fechar o Escopo: Mas me diga algo que você se lembra, para que eu possa definir pra onde você tem que ir…

O Sr. Respondeu: Não lembro muita coisa, lembro que era carpinteiro, que tive um filho, mas engraçado, não fiz sexo pra ter esse filho…

O rosto de S. Pedro se iluminou, escopo fechado, é o Pai do Chefe !!!

Rapidamente determinou alguns anjos pra cuidarem do velho, enquanto ele começava a preparar seu projeto de apresentar o velho a todos…

Tudo pronto, cronograma cumprido e eis que todos os anjos, santos e alguns convidados especiais no “salão nobre do céu”, a melhor banda de querubins com o melhor coral de anjos cantando ao som das trombetas , e o velho adentra a festa, com doces, salgados e comidas de melhor qualidade, tudo perfeito…

O Velho pergunta: Onde esta meu filho?

E o GP S. Pedro, esta vendo aquele jovem bonito, de túnica branca e barba bem cuidada sentado ao lado daquele poderoso senhor resplandecente? É Ele…

O Velho mais do que depressa sai correndo abre os braços e grita: Pinóquio meu filho…

Pois é, faltou o Grupo de Processo de Iniciação…

O Grupo de processo de Iniciação tem por objetivo Definir, com o Maior detalhe possível, o que será feito, o mais detalhadamente possível.

Quando esse grupo de processos não são executados, esquece-se do Óbvio, como na historinha acima, perguntar se o velho lembrava o Nome do Filho… seria bem menos traumático…

São Basicamente dois processos:

- Desenvolver o termo de abertura do processo – este documento é importante porque confirma a existência do projeto, declara as intenções e AUTORIZA o projeto. Este processo diz o que deve ser feito e como esse produto ou serviço vai ser avaliado, e também, QUEM PAGA A CONTA.

- Desenvolver a Declaração de Escopo Preliminar do Projeto - Este processo é importante porque nele se descreve, ainda que em mais alto nível, os requisitos do Projeto.

Pode-se deixar de lado esse grupo de processos?

Para responder isso uso o título de um livro de etiquetas da Bárbara Virgínia: “Poder pode, mas não deve”.

Em projetos pequenos, o impacto de não executar esses processos é pequeno, ele pode ser feito juntamente com o planejamento, porém em projetos maiores, que envolvem várias pessoas, ou varias fases, é extremamente recomendável que se faça e se faça formalmente.

Vão dizer que é burocracia, que é desnecessário, e para projetos que corram sem incidentes realmente são, mas naquele dia fatídico, em que algo acontecer, você vai precisar dele, e ará graças a Deus pela “Burocracia”, ou então, alguém vai chegar ao seu lado e perguntar, como um Anjo perguntou ao GP S. Pedro: “Não te passou pela cabeça perguntar o nome do Filho?”

Antes de começar a escrever, quero dizer que esse artigo é um pouco longo, e nem um pouco técnico, ele é escrito de forma leve (como pretendo fazer em todos os artigos), é voltado mais a quem não é Gerente de Projetos (por isso sua categoria é Introdução), outros temas surgirão, alguns nesse nível, outros mais aprofundados, dependendo do assunto…

Bom, mas deixa eu começar logo…

IMAGINE:

Uma praia paradisíaca, areia branca, gente bonita, eu sentado numa cadeira, óculos escuro, uma cervejinha ou um drink elaborado na mão, sem se preocupar com nada alem de curtir a vida…

Esse é o sonho de muita gente que conheço (e que não conheço também) mas afirmo sem medo: Para a grande maioria delas, arrisco a dizer que para quase a totalidade, isso continuará assim, não passará de um sonho…

Não passará de um sonho porque muita gente não faz nada par a que isso aconteça, diferente de alguns que transforma esse sonho num plano: vou comprar uma casa na praia!

E continuam não conseguindo …

Porque um plano não basta, porque não transformar isso num Projeto de Vida? Seja o Gerente de Projetos de sua vida e você aumentará e muito suas chances de conseguir isso…

É claro que como todo Projeto, existem restrições e riscos, e falaremos disso em artigos futuros deste blog, mas o foco desse primeiro artigo é: Como transformar um Sonho num Projeto de vida?

Primeiro leia bem a página: Gerenciamento de projetos, existe uma definição lá do que é projeto mas vamos definir aqui, de forma simples para ficar claro:

Projeto é um empreendimento TEMPORÁRIO que tem por objetivo produzir um PRODUTO ÚNICO, com um ORÇAMENTO previamente definido.

Olhando com calma essa definição vemos ai 3 variáveis que precisam ser controladas, para se atingir o objetivo do projeto: O ESCOPO(o produto desejado), o PRAZO (é temporário, ou seja, tem um tempo para esse esforço) e o CUSTO (orçamento).

Essas 3 variáveis tem que ser compatíveis para que você consiga êxito, em outras palavras, Não adianta fazer um Projeto para te ruma mansão no carie, em 1 ano, se você ganha salário mínimo…

Dizendo assim é bastante lógico, mas dentro da área de Informática(minha especialidade) já vi muita gente querendo fazer sistemas complexos, em pouco tempo e com pouco dinheiro, é a mesma coisa…

Mas voltemos ao nosso projeto, a primeira coisa é planejar, ou seja, definir as ações necessárias, suas dependências e a melhor seqüência para executá-las, e também é claro, um fluxo de desembolso de seu orçamento, falando em “projetes”, você precisa criar um cronograma.

Se o projeto for muito grande, demandar muito tempo, é complicado prever e controlar tudo que pode acontecer, por isso é aconselhável dividir esse projetão em pequenos projetinhos…

Voltando ao sonho lá de cima, vamos “definir melhor o escopo”, por exemplo

Uma casa no Nordeste, 3 quartos, a no máximo 100m da praia, tranqüilidade financeira, como gosto de trabalhar, um serviço que me permita desfrutar de tudo isso, sem muito stress…

Vamos estabelecer um prazo para isso, digamos 10 anos…

Bom, já temos um Plano, mas ainda não um Projeto de Vida…

Este blog tem por objetivo divulgar o Gerenciamento de projetos, esse sonho que neste artigo traduzi em Plano, mas ainda não em projeto será o ponto de união, usarei a Projetização desse plano para exemplificar tudo o que tenho a dizer…

Vou Começar esse blog com uma série de 5 artigos falando sobre os Grupos de Processo do PMBOK(iniciação, planejamento, execução, controle e encerramento), pretendo colocar 2 artigos por semana (Gerente de Projeto adora um cronograma… *rs), talvez eu intercale com algum outro artigo, talvez não, vamos ver o retorno que tenho, via e-mail ou comentários…

Seja um “StakeHolder” deste “Projeto”, assine o RSS para ler este blog com mais comunidade ou participe dele, comentando ou até mesmo sendo um autor, será bem vindo

Bom Projeto a todos…