Tag Archives: Gerente de Projetos

A oportunidade pode ser única: vá de Paralelismo (fast tracking)!

17 Nov

Sempre que estou prestes a concluir algum projeto gosto de analisar as principais ações adotadas em seu planejamento e execução para avaliar os resultados efetivamente entregues. Desta vez, construirei essa análise com vocês, aqui neste novo post!

Na publicação passada, quando abordei sobre a Eficácia e Eficiência no Gerenciamento de Projetos (clique para ver), procurei enfatizar a necessidade de concentrar esforços em fazer com que o projeto atendesse não só aos requisitos “burocráticos”, mas, principalmente, àqueles que permeassem a qualidade, expectativas e aprendizado.

Ainda influenciado pelos meus vagos pensamentos deste último post, eu comecei a conjecturar sobre um novo projeto que entra em sua Fase de Encerramento. A proposta do projeto está em desenvolver uma Ferramenta de Gestão de Atendimento ao Cliente. Este projeto não chega a possuir alta complexidade de implementação de suas funcionalidades. Entretanto, tivemos (Equipe do Projeto) que fazer uso de algumas técnicas de GP bem interessantes como, por exemplo, o Paralelismo de algumas atividades da Fase de Execução.

Se a análise deste projeto partisse do proposto de [eficácia + eficiência = efetividade] seria ideal envolver as pessoas que demandaram e ajudaram a construir o projeto.  Não que isto não seja importante, ao contrário: é muito importante!!! No entanto, vou restringir, ao menos por enquanto, à análise do uso da técnica do Paralelismo neste projeto.

Pra começar, recorri ao Guia PMBOK v4 para buscar a definição do que seria a técnica do Paralelismo:

“Uma técnica específica para compressão do cronograma de um projeto que altera a lógica de rede sobrepondo algumas fases que normalmente seriam realizadas em sequência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.”

Essa definição não poderia ser melhor!

A história do nosso projeto é bastante simples: as fases de iniciação e planejamento do projeto não foram sobrepostas, ou seja, seguiram bem a metodologia proposta pela empresa. Mas, as Iterações foram reorganizadas de forma a serem paralelizadas. Ao invés de se concluir uma Iteração para então iniciar a próxima, optamos por implementar várias Iterações no mesmo período, mas que seriam complementares entre si.

E por que disso?! PRAZO! PRAZO!! PRAZO!!!

A compressão do cronograma é uma técnica de “redução da duração do cronograma do projeto sem reduzir o seu escopo“.

Lembro que reduzir escopo para alcançar a restrição de prazo nem sempre é uma boa opção: o cliente não vê com bons olhos ter suas necessidades do projeto minimizadas. Ele se sente impotente e, com isso, acaba se afastando do projeto. Em casos assim, é comum utilizar algumas técnicas de Compressão do Cronograma, como a técnica do Paralelismo!

Para que você possa entender melhor o contexto do projeto, nós utilizamos a metodologia da empresa (ativo organizacional) de Gerenciamento de Projetos e Engenharia de Software, a qual estava embasada no Manifesto Ágil. O conceito de ciclos era algo bem forte na metodologia. E para iniciar um próximo ciclo, necessariamente, o anterior deveria estar homologado pelo cliente.

A imagem 1 a seguir demonstra como o projeto foi inicialmente planejado, sem considerar a sobreposição de tarefas:

Imagem 1: execução do projeto de forma linear.

Facilmente, pelo Gráfico de Gantt, podemos constatar as Iterações encadeadas. O Software seria construído de forma incremental. Outra observação que faço está relacionada ao caminho crítico destacado em amarelo, veja como ele foi alterado na imagem abaixo.

Já a imagem 2 demonstra o uso do Paralelismo no projeto para os ciclos de 1 a 5:

Imagem 2: execução do projeto utilizando Paralelismo.

Com essas duas imagens pode-se comparar o quanto o cronograma é modificado e, principalmente, como o caminho crítico é afetado quando utilizamos alguma técnica de compressão do cronograma.

A primeira coisa que me vem à cabeça, quando utilizo a técnica de Compressão do Cronograma, está relacionada à precariedade em seu uso quando temos uma iteração (ciclo) sendo utilizado como insumo para a implementação do próximo ciclo:

1 – A integração do sistema ficou altamente empobrecida. O que gerou dificuldade de compreensão do fluxo de funcionamento do sistema como um todo;

2 – Geração de retrabalho decorrente da integração dos ciclos;

3 – Sensível incremento nos custos do projeto. A linearidade do projeto se perdeu. Novos recursos humanos tiveram que ser adicionados ao projeto para permitir a execução de atividades em paralelo.

4 – As estimativas de duração das atividades foram impactadas, pela falta do insumo para planejamento do próximo ciclo;

5 – Sobrecarga de trabalho para alguns perfis da equipe;

A sobrecarga de alguns perfis como Analista de Testes e o Designer de Interface, se justifica, já que, tiveram que se dividir entre uma e outra iteração. De certa forma, isto os pressionou e comprometeu seus desempenhos. Não havia disponibilidade de contratação ou alocação de outros recursos com este perfil para o projeto.

O versionamento de documentos, a gestão de atividades e priorização ficou dificultada. Muitas vezes, havia necessidade de parar o projeto para sanar dúvidas que deveriam ser respondidas na Homologação de Cada Ciclo desenvolvido anteriormente – lembro que um ciclo serve de insumo para outro.

Naturalmente, o Paralelismo implica em riscos de integração. Quando se utiliza o desenvolvimento simultâneo de ciclos, a integração deve ser muito bem planejada e o custo disso deve ser previamente aprovado. Nem sempre é fácil prever a variação dos custos do projeto quando se utiliza a Compressão do Cronograma!

E o cliente, como fica nesta situação?

É neste ponto que devemos verificar o Custo x Benefício do uso desta técnica de Compressão do Cronograma. O que será escrito aqui não pode ser tratado como regra para todos os projetos, até porque os projetos não são iguais, ok?

O custo do projeto, apesar de ter evoluído, não era algo determinante para continuar ou não o projeto. Basicamente, o esforço de custo estava em alocação de recursos humanos para o projeto. E este custo já estava pago. Se a equipe não fosse alocada para este projeto estaria em outro mais prioritário. Sobre contratos hora homem no serviço público brasileiro, eu publiquei o post que trata deste tema – IN 1 – Procedimentos para o desenvolvimento, disponibilização e uso do Software Público Brasileiro.

No entanto, o cliente enxergou no projeto uma oportunidade de alavancar seu setor de atendimento ao cliente, que até então era precário. Ou seja: o projeto fazia parte de uma estratégia organizacional maior!

Nestes casos, a Gerência do Projeto deve entrar em ação!

Quando se usa o Paralelismo, o cliente tem que está bem mais envolvido do que o normal. É também essencial que o Cliente esteja ciente dos riscos envolvidos nesta operação. Ele deve ser parceiro do projeto!

Para gerenciar as expectativas do cliente, o Gerente de Projetos deve dar autonomia a equipe técnica para resolver questões de implementação e, principalmente, necessita mantê-lo informado da relação de evolução do Escopo x Tempo x Custo. A análise de valor agregado é fundamental para que o cliente veja o quanto a decisão de antecipar o prazo custou ao projeto!

Lembro que a oportunidade para realizar o projeto era única, já que, havia recursos disponíveis, patrocínio e vontade política!

No entanto, mesmo com os entraves apresentados acima, seria o Paralelismo o fim dos tempos no Gerenciamento de Projetos?!

Não! De forma alguma!

Tente enxergá-lo como uma oportunidade. Explico:

Propiciar aos clientes da empresa um atendimento mais qualificado  é algo que deve ser visto como investimento e não custo. O prazo deveria ser atendido, já que a vontade política para realizar o projeto passava por essa restrição. Em qualquer projeto, não se pode perder o patrocínio, ainda mais quando voltado para órgão público.

Neste caso, a Técnica de Compressão do Cronograma baseada no Paralelismo é muito importante.

Aí convenhamos: mesmo com todas as dificuldades no Gerenciamento do Projeto e nos eventuais fracassos obtidos em relação a isso, sob a ótica do cliente o projeto atendeu as expectativas técnicas e negociais, já que cumpriu com seu escopo e com os objetivos políticos determinados para ele.

Veja o porquê do dilema de Eficácia e Eficiência continuou a ventilar os meus pensamentos…

É isso! Continue visitando o blog!

Até a próxima!

P.S.: este blog concorre ao TOP BLOG 2011. Não se esqueça de apoiar!

Por favor, mais Eficácia no Gerenciamento de seus Projetos!

27 Out

A dinâmica da disciplina de Gerenciamento de Projetos é algo realmente apaixonante. A disciplina tem o poder de transformar, diga-se de passagem, com extrema facilidade, o presente em passado e o distante futuro em realidade absoluta. E isto não acontece por acaso: é espantoso e gratificante ver o quanto se estuda os temas relacionados ao Gerenciamento de Projetos.

Não é raro observar o grande número de autores investindo seu tempo em aprimorar a aplicação do Gerenciamento de Projetos nas organizações. Mais do que isso, é muito bom ver que os profissionais que operam o Gerenciamento de Projetos no dia-a-dia têm o prazer em contribuir com a melhoria contínua dos conceitos envolvidos com a matéria.

Até ontem, por assim dizer, havia total foco em atingir, com máxima precisão, os indicadores de custos e tempo propostos para um projeto. Para muitos, projeto bem realizado era aquele que cumpria suas metas de orçamento e prazo com perfeição. Isto não é de todo errado, já que se buscava a eficiência dos projetos.

Entretanto, o Gerenciamento de Projetos se propõe a ser mais do que dar aos GP’s ferramentas administrativas e orçamentárias para planejar e monitorar um projeto. Não que estas ferramentas sejam desnecessárias, ao contrário, são essenciais. Porém, não é o core do Gerenciamento do Projeto. É neste ponto que gostaria de compartilhar algumas posições sobre a Eficiência e a Eficácia no Gerenciamento de Projetos.

Confesso que não é raro eu confundir Eficiência com Eficácia. Mas, quando isso ocorre, sempre recorro a uma citação de Peter Drucker que diz o seguinte:

“A eficácia é o fundamento do sucesso – eficiência é a condição mínima de sobrevivência após o sucesso ter sido atingido. A eficiência se ocupa em fazer as coisas corretamente. Eficácia significa fazer as coisas certas.”

Compreender isso é realmente importante!

A reflexão sobre Eficiência e Eficácia, no entanto, tem seu inicio na verificação do estágio atual de maturidade de Gerenciamento de Projetos em que a organização se encontra: para aquelas organizações que já atingiram seu sucesso inicial, não seria o momento de caminhar em direção à eficácia dos processos de Gerenciamento de Projetos?

É uma questão que parece óbvia…

O Autor Harold Kerzner ensina que há um Ciclo de Vida da Maturidade do Gerenciamento de Projetos na organização, no qual alguns desafios são apontados em cada fase desta maturidade. A imagem abaixo retirada do livro Project Management – a systems approach to planning, scheduling and controlling do autor citado define bem isto:

Compreendido o estágio que o Gerenciamento de Projetos se encontra, agora é hora de pensar na Eficácia do processo!

Já o conceito de Eficiência e Eficácia para o Gerenciamento de Projetos é tratada, de acordo com a autora Johanna E. M. Schönrok, da seguinte forma:

A eficácia do projeto refere-se à reunião da qualidade do produto definida pelas especificações e requisitos e considera-se a eficiência do projeto sendo definida pelo grau de realização do projeto dentro do prazo e orçamento.

Veja o quanto isso é importante: basta cumprir o projeto conforme seu planejamento de custo e prazo para ele ser considerado “realizado com sucesso”?

Em minha opinião não!

Considero que se dar por satisfeito exclusivamente com a Eficiência do Projeto é muito pouco pelo o que se propõe para o Gerenciamento de Projetos.

Gerenciar Projetos é atingir objetivos maiores!

Pouco adianta cumprir o prazo e o orçamento se não atingir aos objetivos especificados, além de não conseguir provar os motivos que deram existência ao projeto.

É preciso pensar a avaliação do projeto de outra forma: eficácia!

Veja: se os objetivos de qualidade e requisitos do projeto foram cumpridos entre 90% a 95% do proposto e, no entanto, o prazo superou as expectativas em 20% o projeto teria fracassado?!

Se olharmos para a eficiência do projeto, a resposta seria sim!

Mas o projeto atingiu 90% a 95% dos requisitos de qualidade proposto!!!!

Se este percentual foi acordado entre cliente e executor, o projeto foi realizado de uma maneira correta! Pois ele foi eficaz!

Outro aspecto que chamo a atenção é quanto a Gerência de Recursos Humanos em projetos. Uma das vertentes do Gerenciamento de Projetos está na disseminação do conhecimento. A organização que já se encontra em fase avançada de maturidade consegue reter e disseminar o conhecimento adquirido ao longo do desenvolvimento do Projeto. Ao fazer com que a equipe do projeto se desenvolva durante a realização do Projeto, a organização também se torna eficaz.

Veja que este aspecto de mensurar aprendizagem nem sempre é tão simples, mas é um critério tão importante quanto os critérios de custos e prazo. Ter metas relacionadas ao desenvolvimento de Recursos Humanos e de registro e disseminação de Lições Aprendidas também faz que o projeto seja norteado pela eficácia e não somente pela eficiência.

Para muitos o que foi dito é óbvio, mas penso que estamos a evoluir para explorar a potencialidade do Gerenciamento de Projetos de forma completa. E no dia que isso acontecer, teremos organizações melhores e mais adequadas ao mundo atual.

Entretanto, o caminho da eficácia é longo, mas, possível!

Até a próxima!

Referências:

A TI é o foco? Cuidado ao responder.

2 Set

Não restam dúvidas que a área de tecnologia da informação (TI) é dinâmica e de vanguarda. E por isso, gostaria de compartilhar uma inquietude: se estamos envolvidos em uma área que olha sempre pra frente, que precisa a todo instante de recursos financeiros e ao mesmo tempo não gosta de ser identificada com uma área que consume muito pra pouco, então porque as estruturas de TI são semelhantes (para não dizer idênticas) a de outros setores, como contabilidade, RH, financeiro, etc.?

Antes de olharmos para metodologias e frameworks de governança, como ITIL e CoBiT, é necessário dizer qual será o posicionamento da TI frente às outras unidades de negócio da organização.

Basicamente: ela será descentralizada ou centralizada?

Isto é algo que realmente importa. Definir como a TI está situada dentro da empresa é fundamental. Acredito que muito se gasta com a TI por ela não ter o posicionamento correto. Ou seja, o modelo de outras unidades não serve para a TI!

Geralmente, os profissionais de TI e, especialmente, os Gerentes de Projetos, relacionam-se com pessoas de diversas áreas de conhecimento, principalmente por que precisamos entender o que e como fazem, para então propormos a melhor solução.

Isso traz a nossa área uma característica muito, mas muito especial: ela tem os profissionais que entendem como as unidades de negócio da empresa trabalham e como elas podem se integrar. A TI não é  fim nela mesmo. Engana-se o profissional que acha que isso é diferente.

Como consequência disso…Nós conhecemos os processos, melhor de que qualquer um! Isto é um fato!

Bom, mas o que isso tem haver com que coloco sobre a TI ser o foco?

Dizer que a TI é suporte parece ser simples, não é? E você com certeza já escutou isso em várias palestras, seminários, programas de auditório, entre outros meios…

Então, se somos meio, porque centralizamos a nossa gestão?

Onde quero chegar com essa conversa: os clientes conhecem do seu negócio e nós conhecemos os caminhos para que eles produzam de maneira mais eficaz e eficiente. Sendo assim, porque cada unidade de negócio não ter sua equipe de TI dedicada?!

Evidente que esta teoria não é minha. Muitos autores já propõe um modelo descentralizado de TI. Antes realmente achava essa ideia absurda, mas atualmente vejo que ela pode ser a saída.

Muitos Gerentes de Projetos tem o sonho de trabalhar em uma estrutura totalmente projetizada, acham que este é o caminho do sucesso. Mas sabemos as desvantagens que este tipo de estrutura pode trazer.

Estas mesmas desvantagens, como: perda de conhecimento, alto custo com equipes, dificuldade em se ter padrões e integrar soluções, desmotivação da equipe, etc. também acontecerão se a TI for descentralizada.

No entanto, pense comigo: se focamos nas unidades que tem prioridade de orçamento e projetos, consequentemente, a empresa, no sentido global, alcançará os resultados de maneira mais rápida e com maior qualidade. Com a TI não deve haver intermediários. A TI é meio, certo?! Não se pode ter uma estrutura totalmente funcional para a organização da TI.

Por mais que isso possa parecer subversivo, a ideia tem que ser discutida. Dê para cada unidade de negócio a sua equipe de TI. As reclamações que somos inoperantes vão diminuir sensivelmente. Indo além: os responsáveis pelas áreas que atualmente só demandam, passam a ser responsáveis pelo sucesso ou fracasso da equipe e do projeto. Para mim isso é fundamental!

E nós como ficamos?

Os gerentes de projetos, com o apoio de um PMO, será o elo entre a operação e a gestão de TI.

Por falar em gestão de TI, ela deve estar preocupada com:

  • Metodologias;
  • Padrões e padronização;
  • Integração;
  • Estabelecimento de políticas;
  • Acompanhamento de portfólio;
  • Suporte;
  • Busca por novas tecnologias, pesquisa…; e
  • Desenvolvimento humano.

Indo um pouco além, penso que nem sobre o investimento a Gestão de TI deverá ser responsável. A organização, neste caso, contará com um BELO de um PLANEJAMENTO ESTRATÉGICO que alinhe as unidades e direcione os recursos. Por isso, a organização será responsável pelo investimento e não um ou outro gestor.

Alerto para que isso não deva ser interpretado com um sonho, mas sim com uma premissa! Planejamento é obrigação e não acessório.

Para finalizar, recentemente li um artigo sobre “quais os três cargos de TI que devem sobreviver no futuro” e pensei: a TI descentralizada está cada vez mais próxima, ou melhor, já é uma realidade!

Se você tem uma opinião diferente ou concorda comigo, opine!!!

Abraços e até a próxima!

———————————————————————–

Sobre este assunto visite:

http://www.malima.com.br/article_read.asp?id=634

http://blog.opus-software.com.br/?p=170

http://olhardigital.uol.com.br/negocios/digital_news/noticias/quais_os_3_cargos_de_ti_que_devem_sobreviver_no_futuro

http://www.bain.com/bainweb/PDFs/cms/Public/Voce_tem_organizacao_de_ti_certa_Portuguese.pdf

http://www.tiespecialistas.com.br/2011/01/repensando-ti-na-estrutura-organizacional/

Imagem retirada de:

http://promoview.com.br/artigos-e-cronicas/131368-um-show-no-atendimento-por-paulo-araujo/

Scrum Master vs Gerente de Projetos, PMP: Presente e Passado?

4 Jul

Se você ainda não vivenciou uma situação parecida com que vou descrever, então imagine: de um lado um ScrumMaster certificado (CSM) e do outro um PMP, e algumas pessoas em volta observando a discussão de quem é o melhor perfil para gerenciar projetos!!!

Seria mais uma daquelas discussões intermináveis?!

Pensando nisso, resolvi escrever este post: seria o CSM o presente e o PMP o passado na gerência de projetos?

Lembro que a proposta de ser iterativo e incremental, pregada pelo Scrum, não é nova. Há várias metodologias na Engenharia de Software que pregam a construção baseada em ciclos e releases. Não pretendo com isso minimizar a importância do Scrum, ao contrário. Eu vejo a força desta metodologia na forma de organização do time do projeto e na condução das iterações (sprints) durante o desenvolvimento do projeto, além  da questão da qualidade nos produtos desenvolvidos. Realmente acredito nesta proposta! Mas não é isto que torna o ScrumMaster o grande profissional de gerenciamento de projeto.

De acordo com o Scrum Guide de 2010, a equipe Scrum (Scrum teams) é designada para otimizar a flexibilidade e produtividade do projeto; e para este fim, a equipe é auto-organizada, são cross-functional  (time com diferentes experiências e habilidades voltadas para um objetivo comum) e trabalham por interações.

Faz parte da equipe Scrum: o ScrumMaster; o Proprietário do Produto e a Equipe Scrum.

O ScrumMaster é o responsável por garantir que o processo é compreendido e seguido por TODOS.

Atenção! É também premissa básica, super importante, fundamental etc. etc. etc., que o PMP garanta o processo adotado para o gerenciamento do projeto e que todos os envolvidos tenham ciência deste processo e o execute de maneira coerente, ok?!??!

As figuras do Sponsor (PMBOK) e do Proprietário do Produto (Scrum) dão um encaminhamento distinto para a atuação dos dois perfis, veja:

O Proprietário do Produto é o responsável por maximizar o valor do trabalho que o Time SCRUM realiza.  Já o Sponsor, como apontado no PMBOK, é a pessoa ou grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto.

Fundamentalmente isso já traz uma consequência para a atuação do ScrumMaster e o Gerente de Projetos que se baseia no PMBOK, concorda?

Observe que o Proprietário do Produto atua em conjunto com a equipe para que o projeto atenda aos requisitos necessários. Já  Sponsor é uma espécie de suporte ao gerente de projeto, para tratar de assuntos relacionados à mudança, além de ser o porta-voz do gerente de projetos para os níveis gerenciais mais altos.  Esta diferença é realmente importante e na prática acaba fazendo toda a diferença.

O ScrumMaster de acordo com o Scrum Guide:

  • Trabalha com os clientes e gestão para identificar e indicar um Proprietário do Produto.
  • Ensina o Proprietário do Produto como fazer o seu trabalho. Espera-se que o Proprietário do Produto saiba como conseguir otimizar valor usando Scrum. Se não, temos o ScrumMaster responsável.
  • Pode ser um membro da equipe, por exemplo, um desenvolvedor que executa tarefas no Sprint (iteração)No entanto, isso muitas vezes leva a conflitos quando o ScrumMaster tem que escolher entre remover impedimentos e realizar tarefas.
  • Nunca deve ser o Proprietário do Produto.

O Gerente de Projetos segundo o Guia PMBOK:

  • Pessoa designada pela organização executora para atingir os objetivos do projeto;
  • Sua autonomia depende do tipo de estrutura organizacional que projeto será desenvolvido;
  • Requer habilidades da área específica e das proficiências ou competências de gerenciamento geral;
  • Ter capacidade de realização;
  • Ter liderança;
  • Capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge os objetivos e equilibra as restrições do mesmo;
  • Dependendo do contexto do projeto, o GP poderá determinar a necessidade de um controle mais eficaz sobre certas entregas;
  • Cabe ao Gerente de Projetos e a sua equipe, determinar o método mais apropriado de execução do projeto.
  • Gerenciar as expectativas das partes interessadas;
  • Desenvolve o plano de gerenciamento de projeto e todos os componentes relacionados;
  • Identifica e monitora os riscos;
  • Fornece relatórios precisos e oportunos das métricas do projeto;
  • É o líder responsável pela comunicação com todas as partes interessadas;

As funções do Proprietário do Produto e do ScrumMaster são bem definidas e claras. Já o PMBOK dá ao gerente de projetos a responsabilidade sobre atividades que poderiam ser compartilhadas com o Sponsor do Projeto.

Resultado disso na prática:

Bom, aí penso que nem todos os projetos cabem, unicamente, em um ou em outro perfil. O contexto mais uma vez vai direcionar qual a melhor forma de orientar e conduzir os trabalhos.  O momento atual do manifesto ágil é muito bom, mas não significa que a filosofia PMI seja ultrapassada, afirmar isso, a meu ver, seria leviano.

Os profissionais PMP passam por um regime mais rigoroso de certificação que os certificados ScrumMaster, isto tem que ser levado em consideração ao avaliarmos os perfis. 

O IT-Management, baseado em uma pesquisa realizada pelo site de empregos de TI, Dice Learning, publicou sobre as certificações percebidas como de grande valor, e a certificação PMP aparece no topo, sendo que a CSM nem na lista aparece. Pense nisso!

O mercado, no entanto, quer alguém que responda com mais agilidade e seja menos burocrático ou estritamente metodológico. Por muitas vezes, já presenciei gestores importantes referindo-se aos PMP’s como “grandes burocratas de alto custo”.  Vejo como demasiadamente dura a afirmação.

Talvez, digam isso por perceberem que os profissionais que conduzem projetos, baseados no manifesto ágil, dão maior foco nos resultados funcionais do projeto. No entanto, vejo que os PMP’s, para projetos de alta criticidade, que requerem maior controle de custos, riscos e recursos, são os mais adequados.

Para que funcione bem, o Scrum requer uma equipe mais experiente, que saiba como se auto-organizar e que tenha em seu “líder” alguém que seja um facilitador para os problemas que surgem no dia-a-dia do projeto e garanta o processo. Por mais belo que isso seja na teoria, nem sempre é fácil de realizar na prática.

Finalizando: nem o PMP é passado e nem o CSM é o presente. Ambos são realidades! Quem é melhor… Aí é uma discussão interminável, do tipo projetista JAVA  vs projetista C#…

Abraços e até a próxima!

Comece seu projeto pelo inicio!

13 Jun

O título parece ser  redundante?   Só parece  …. e você vai compreender o porquê (se você continuar lendo, claro!)

Por incrível que pareça começar o projeto pelo seu inicio é muitas vezes uma tarefa árdua, e o pior… em diversas situações este fato (de iniciar pelo inicio) é totalmente negligenciado por nós e pelos patrocinadores do projeto. O agravante para nós é que aceitamos a “imposição” do “execute já!“, sem muitas vezes argumentar.

Por isso, o que quero mostrar a você neste post é a importância do pré-projeto. Espero que ao final da leitura você se sinta motivado a mobilizar os principais interessados do projeto para que deem a ênfase necessária a esta fase.

Veja algumas interessantes definições sobre os processos de iniciação, segundo o guia PMBOK v4:

  • “o uso do processo de iniciação no início de cada fase ajuda a manter o foco do projeto na necessidade empresarial para o qual o mesmo foi criado”
  • “os processos de iniciação podem ser executados por processos organizacionais, de programas ou portfólios externos ao escopo de controle do projeto.”

Veja o exemplo que é dado no guia:

  •  antes de iniciar um projeto, a necessidade de requisitos de alto nível pode ser documentada como parte de uma iniciativa organizacional maior.”

Só este exemplo contextualiza tudo que penso sobre a importância de um início bem realizado!

Mas apresento algumas atividades, que se você fizer, aumentará as chances de sucesso do projeto:

  • Primeiro: identificar staekholders tenha parceiros, gere comprometimento!
  • Segundo: mapear a origem da demanda do projeto – compreenda a necessidade do negócio e dê importância aos objetivos estratégicos.
  • Terceiro: realizar uma análise de viabilidade técnica para implantar o projeto – será se é possível fazer o que estão querendo? O custo de pesquisa não será maior do que o retorno do produto final?

Algo que sempre procuro realizar quando vou fazer um projeto, seja ele de qual tipo for, é questionar sobre como planejar alguma coisa, se:

Eu não sei o que querem,

Eu não sei quem são as pessoas que querem e para quê querem,

E se é possível ser feito.

A fase de iniciação e os processos que a suportam servem exatamente pra isso: levantar todas as informações necessárias para iniciar o projeto, ou seja, preparar o terreno para dar o passo seguinte –  planejamento do projeto.

Bom, e o Termo de Abertura do Projeto?

Para quem faz a prova de certificação PMP sabe que a coisa mais importante  – para efeitos de prova – do Termo de Abertura é a FORMALIZAÇÃO da indicação do Gerente de Projetos para o projeto. Até considero isso uma premissa. Mas o problema neste posicionamento é que, ao meu ver,  restringe o  valor ao Termo de Abertura do projeto.

Explico:

Novamente citando o guia, “o Termo de Abertura é o documento que formalmente autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas.”

Veja como o pré-projeto é importante!

Este termo, depois de preenchido e assinado, é que vai demonstrar todo o entendimento prévio daquilo que se consolidou da pesquisa inicial sobre o projeto.

Mas aí vem a pergunta: quem é o responsável por coletar todas as informações a serem consolidadas para se autorizar o projeto, já que não se tem, AINDA, um gerente de projetos formalizado para isso?

Antes, vamos combinar uma coisa: nem tudo é responsabilidade do gerente de projetos, ok?

Lembro que: só há gerente de projetos se houver projeto e eu estou falando de uma etapa que antecede ao projeto.

Para isso, nada mais justo que o patrocinador – apoiado por perfis estratégicos e técnicos – ou um comitê levante essas informações. Deste comitê não poderia sair o GP do projeto? Em minha opinião, sim!

O que pretendo mostrar a você é que o planejamento do projeto é fundamental, não restam dúvidas! Só que, tão fundamental quanto o planejamento é saber o que planejar.

Este é o principal objetivo do pré-projeto. É neste período que os objetivos principais são definidos. O planejamento deve estar voltado a viabilizar o alcance destes objetivos. O erro, geralmente cometido, está no fato do planejamento ser realizado “apenas” para viabilizar a execução do projeto.

O planejamento não é algo solto, ele tem origem… a fase de iniciação. É nesta fase que o planejamento, mesmo que indiretamente, se inicia.

Aí vem a questão do primeiro parágrafo: iniciar um projeto já com a indicação do gerente de projetos e a ele apenas fornecer as restrições de prazo e custo, além de uma visão bem mais ou menos do escopo é o correto?

Muitas vezes é assim que um projeto inicia. Não pelo começo, mas pelo meio ou pelo fim…

Talvez você já tenha vivido a experiência do “patrocinador” dizer: “execute! Você foi escolhido porque acreditamos em seu trabalho!”.

A questão não é acreditar ou não no trabalho de alguém, mas sim de possuirmos informações suficientes para atingir aos objetivos propostos.

Muitos projetos fracassam ou gastam mais tempo que o necessário com o planejamento porque não se tem as questões preliminares básicas respondidas.

Para finalizar, pense sempre e indague seus “admiradores” sobre as questões abaixo:

  • Existe um plano maior de onde originou a demanda para este projeto?
  • Por que querem (área, gerente, presidente, empresa) o projeto?
  • Quais os objetivos e metas que se pretendem alcançar com este projeto?
  • O que realmente pensam que deve ser produzido? Qual o resultado que esperam?
  • Há viabilidade técnica de se fazer o que querem?
  • Quem é a comunidade impactada pelo projeto? (nunca se esqueça disso)
  • Quem está interessado neste projeto? (nunca se esqueça disso)
  • Qual o resultado financeiro que se espera com o projeto? (muito importante!)

Respondidas essas perguntas, vamos iniciar o projeto. Bem-vinda a fase de planejamento!

Até a próxima!

%d bloggers like this: