Hoje no mundo dos projetos tudo requer controles e visão de: começo, meio, fim e até mesmo uma premonição do que pode dar errado e não importa o tipo ; em tecnologia, construção ou até mesmo os projetos pessoais.
Mas será que realmente podemos prever tudo, podemos controlar tudo em um projeto?
Em gestão de projetos é comum ver os gerentes de projetos, tentarem estimar as datas de entrega e o final do projeto. Sendo que muitos destes projetos podem durar anos.
Pretendo fazer uma série de posts falando sobre quebra de paradigmas em gestão de projetos, colocar o que realmente acontece e o que temos que fazer na prática. Existe muito material acadêmico, frames e metodologias dizendo o melhor dos mundo, as mais conhecidas são o PMBOK , Price 2 , Ágeis entre outros mas vamos ao que realmente interessa.
Voces perceberão que nestes posts vou misturar um pouco de gestão de projetos tradicional e técnicas de métodos ágeis. Acho importante saber todas estas metodologias e frames, mas o ideal é usar aquilo que nos cabe e encaixa no nosso dia a dia. Sempre é bom lembrar que nao devemos seguir as metodologias , elas foram criadas para nos dar um direcionamento.
Vamos agora aos paradigmas propriamente ditos. Reflita um pouco sobre o que vamos falar:
1 – É possível dizer que o produto do projeto será o mesmo durante toda a sua execução?
Bem , existem muitas variáveis durante o andamento de um projeto para afirmar ele será o mesmo do começo ao fim.
Mudanças do mercado , leis fiscais, e até mesmo o próprio cliente podem requerer que mude, ou seja mudança de escopo. Assim logo existem as mudanças de escopo , de prazo, de qualidade, e até mesmo mudanças de pessoas.
A possibilidade do cliente não saber na integra o que está pedindo é muito alta e no meio do projeto tudo pode mudar.
2 – É possível prever tudo o que vai dar de errado ou certo no projeto ?
Como já mencionado , não é possível prever todos os riscos, nem mesmos os riscos positivos ( falaremos mais em detalhes sobre riscos positivos… mas sim, eles existem e deixamos passar e ninguém faz ideia de como podem somar no projeto. Um rápido exemplo é, imagine um projeto onde vamos construir uma linha de trem no deserto, o risco positivo é, achar um oásis no meio deste deserto, imagine o valor disso…)
E como o próprio nome já diz, Risco , Vamos ao seu significado pelo dicionário
risco – sm (ital rischio) Possibilidade de perigo, incerto mas previsível, que ameaça de dano a pessoa ou a coisa. R. bancário, Com: o que decorre do negócio entre banqueiros ou entre o banco e os correntistas. R. profissional, Dir: perigo inerente ao exercício de certas profissões, o qual é compensado pela taxa adicional de periculosidade. A risco de, com risco de: em perigo de. A todo o risco: exposto a todos os perigos. Correr risco: estar exposto a
By Dicionário Michaellys
3 – Realmente focar na entrega do projeto é algo correto?
Creio que este seja o maior paradigma a ser quebrado pois muito se fala em entrega, em prazo, em cumprimento de datas, em pactos de baseline e pagamentos amarrados a estas datas e por ai vai. Em resumo, um pacto quase que de sangue. Também veremos mais abaixo que a questão pagamento pode afastar a parceria em um projeto, limitando a uma guerra entre Empresa Cliente x Empresa Prestadora de serviço, ( quando o projeto é externo ou quando o projeto é interno algumas coisas mudam).
Pelo fato de já existir um padrão onde as datas são pactos para pagamentos e contratos amarram isso e tudo mais.
Hoje existe uma preocupação muito grande em cumprir datas, em entregar. Porém será que todo este esforço realmente irá entregar o que se precisa? Qual o beneficio deste projeto ou desta entrega para o todo? Será que este é o correto a ser feito?
PMOs (Escritório de Projetos ) e Gerentes de Projetos, sempre procuram analisar em suas empresas as viabilidade de algo e sempre se perguntam. “Estamos fazendo o projeto certo?” Lembrando que esta pergunta deve ser pensada levando em consideração os valores da empresa, missão , visão, e tudo o que tiver no business plan ou mapa estratégico da empresa ou da “área” ( cada área de uma determinada empresa pode ter o seu mapa estratégico )
Isso é muito bom quando se trata de portfólio ou de programa de projeto ( Existe um erro muito comum em se confundir portfólio e programa,em um post futuro pretendo abordar estas diferenças ) . E dentro do projeto, temos esta preocupação? Creio que seja uma minoria que pense neste assunto.
Porque a responsabilidade do produto do projeto é do gerente de projeto de forma integral e não compartilhada?
Uma das formas de se resolver este problema é atuar em um modelo de compartilhado de responsabilidade, e papeis.
Envolver o cliente ou parte interessada no produto do projeto para uma participação mais ativa mais próxima.
Vamos entender as origens de alguns dos nossos problemas.
A gestão de projetos teve sua origem com as melhores praticas de engenharia civil e de produção, e em 1970 se convencionou um frame ou um processo chamado Waterfall. Em resumo, o este modelo segue etapas como as de linha de produção, ou seja com fases e processos bem definidos e estruturados.
Requerimento ou Requisitos
Desenho
Implementação
Verificação
Manutenção
Outro modelo bem conhecido é :
Iniciação ——-> Planejamento ——> Execução e Monitoramento ——> Encerramento
Se analisar estes processos você verá que em teoria é um caminho só de ida e no meio dele você tem uma “retroalimentaçao”. Mas entenda que esta prática pode não ser tão saudável em alguns tipos de projeto.
Outra prática são as entregas, geralmente com datas fixadas, e assinadas com sangue em seus contratos entre cliente e gestão do projeto.
No entanto, existe uma matéria no PMBOK falando apenas sobre aquisições, que acho que é pouco explorada pelas empresas, na hora de avaliar um projeto. Não acredito em uma avaliação de projeto somente através de sua rentabilidade. Mas acredito no beneficio deste projeto, e o ponto mais difícil é voltar a medi-lo.
Bem , já se perguntou o quanto isso pode travar o produto do projeto?
Hoje temos a restrição em projetos que basicamente é tempo , custo , escopo, qualidade. Todas elas com os seus cálculos, formulas e afins. O que é muito importante saber, mas em linhas gerais, as restrições estão muito mais focadas em tempo e custo. Mas é importante saber que qualquer uma destas restrições afeta a outra, ou seja, se eu reduzir o custo do projeto com certeza devo ver onde será a penalização, em qualidade, ou em tempo, ou em qualidade
São restrições importantes e devem ser vistas , avaliadas e revistas pela gestão do projeto. Mas como aplicar isso?
Desembaraçando o projeto e seus objetivos ( geralmente este item consta em um documento de plano do projeto ). Ser desembaraçado não quer dizer não possuir um controle ou regras, mas sim usar o que realmente trará valor. ( neste caso a frase menos é mais, se aplica perfeitamente)
Os projetos que seguem métodos ou metodologias ágeis trazem algumas idéias bem legais que podem ser aplicadas em seus trabalhos, particularmente não sou fã de adotar uma metodologia a risca,( como um amigo meu comentou , sou um xiita em determinada metodologia) mas sim utilizar o que melhor pode agregar.
Seguem algumas idéias tiradas do manifesto ágil. Vamos ver alguns detalhes sobre elas:
Gosto muito deste ponto de vista como veremos abaixo, adotar princípios. Se temos princípios temos um caráter, logo atribui aos meus projetos o seguinte pensamento ( se existem princípios eu posso formar o caráter do meu projeto). Reflita nisso, pois o projeto nada mais é que reflexo do gerente de projetos e o sponsor / beneficiado do projeto)
Alguns princípios importantes, seguem eles :
Lembra aquela frase “O cliente tem sempre razão” enfim, filosofias a parte, o cliente nem sempre pode ter a razão , mas ele sempre quer a satisfação no projeto
Pode parecer bem óbvio mas não é, ( nem sempre o óbvio é tão obvio) em um muitos projetos existem conflitos de interesses e a gestão disso não é tão simples. Em um único projeto podem existir no pelo menos 4 conflitos de interesses, porém o o mais interessante é que na visão das partes interessadas cada uma tem seu meio de chegar no objetivo. Para isso você precisa conhecer quem pode trazer impactos ao seu projeto, eu chamo isso de “conhecer os atores do projeto” . Outro ponto importante citado acima é; estamos realmente entregando algo que tem valor?
Sempre falo que o gerente de projeto é um mordomo , está na casa do dono do projeto
Quando menciono valor não é simplesmente a analise de Valor Agregado, ( Formula EVM ) mas algo que o cliente consiga realmente usar.
Todos sabemos que mudanças são inevitáveis nos projetos mas na maioria existe uma certa resistência em se mudar; isso se deve ao tipo de foco que os gerentes de projetos estão trabalhando.
Foco total na entrega mas será que o gerente faz a seguinte pergunta ” Estamos fazendo as entregas certas?”
Este é um tema que gosto muito de falar. Entregas frequentes, são importantes, e acalmam o cliente em relação a ver o produto.
No geral os BIGs projetos tendem a ser longos e com datas dos milestones ( um marco do projeto) fixadas e assinadas com sangue , mas se observarem os projetos possuem mudanças e elas só serão aplicadas depois de um milestone ser entregue, e isso pode demorar meses. Por isso sou adepto das entregas parciais e mais curtas onde é mais fácil efetuar um pequeno ajuste do que toda uma mudança do produto.
Bem , andar em conjunto em um projeto pode ser algo talvez distante pois em sua maioria os projetos são divididos em uma empresa cliente e uma empresa prestadora de serviço sendo que algumas questões contratuais as afastam e muitas vezes os pagamentos são muletas para muitas desculpas no projeto.
Se você observar quando se fala em fechar um contrato de projeto, o ponto mais discutido são ; ( seguindo esta ordem de importância )
No contrato não segue esta ordem , mas na cabeça dos envolvidos na hora de assiná-lo segue esta ordem de importância, logo podemos perceber que o projeto terá problemas de relacionamento , ou seja, equipe e Stakeholders não irão andar juntos.
Estabelecer a parceria é muito mais do que trabalhar no projeto. Algumas literaturas como ” A arte da Guerra de Sun Tzu ” e outros, falam que é mais vantagem ter um aliado do que um “amigo” pois o objetivo em comum é o mesmo. O “amigo”pode não ter os mesmos objetivos que você e em uma batalha fugirá no primeiro momento de luta pesada.
Estas literaturas trazem muito sobre estratégia e como lidar com algumas coisa do nosso dia a dia. Agora cabe a nós estabelecer uma disciplina sobre estes ensinamentos, adapta-los e aplica-los.
Em um próximo post quero falar sobre como fazer uma parceria na prática e como trabalhar a negociação.
Minha recomendação é que seja feito realmente uma parceria, envolvimento real e não apenas as formalidades das que existem em um kickoff de projetos ( evento de formalização do inicio de um projeto). Em um projeto existe muito mais do que simples entrega e prestação de serviço.
O próximo post será : Entenda os Atores do seu Projeto
Até lá 🙂
Experiência em Gerenciamento de Projetos,Programa e Portfolio ( PMO.) e Scrum Master Priorização e balanceamento de portfólio de projetos. Atuação em resolução de conflitos, motivação,negociação e gerenciamento de Crise Conhecimento em licitações públicas(lei 8666). Conhecimentos em projetos de CCM, IAM, SSO
You must be logged in to post a comment.
