Pode parecer estranho mas em muitos casos você está em um projeto que não tem o apoio da sua gerência. Ou é aquele comprometimento apenas com o resultado do tipo "Não quero saber como e quem, quero saber do quando!".
Acho que este tipo de gerente (Funcional) acabam por sobrecarregar o gerente do projeto, uma vez que, este acaba tendo que tomar atitudes muitas vezes que não são de sua alçada. Por exemplo, todo projeto tem a boa e velha scalation list. Com base nela, você vai até o seu gerente para reportar uma situação que deve ser tratada em uma camada acima do projeto. Eis que vem a resposta -"Toma aqui o telefone do diretor de nosso fornecedor, liga para ele e resolva". Então para que serve o scalation list, hierarquia e demais "Fatores Ambientais e Ativos de processos organizacionais"? E o mais grave, o plano de gerenciamento de recursos humanos com as atribuições e etc.
Há algum tempo, passei por uma situação de ingerência de um fornecedor por duas vezes. Como gerente do projeto solicitei a retirada deste recurso do projeto. Por não possuir o apoio necessário e devido ao fato de que o poder à mim concedido para "alocar,retirar e substituir recursos quando necessário" era apenas uma mera informação do plano de recursos humanos e que não "se deve aplicar tudo ao pé da risca" - Palavras do meu gerente na época - o recurso foi mantido. Detalhe a retirada tinha sido decidida por uma grande questão de falta de respeito com os demais membros da equipe - coisa séria mesmo.
Agora vamos pensar. Como fica um gerente de projetos que decide algo no projeto e o seu próprio gerente tira a sua autoridade? Como este recurso irá se comportar frente alguma cobrança que parta de você?
Acho que esta é uma das TOP10 - de situações em que um Gerente de Projetos deve se retirar por conta própria do projeto - A falta de apoio do gerente / patrocinador ou como eu gosto de chamar o "Fogo amigo".
sexta-feira, 4 de dezembro de 2009
quinta-feira, 26 de novembro de 2009
Análise de Requisitos
Trecho de um edital:
"O rack deve ser de 19" com no minimo 42 Us, onde 6us devem ser destinadas à instalação de servidores. Servidores estes que serão instalados pela equipe de TI da contratante."
O que a pré vendas inseriu no projeto para aquisições?
Rack Aberto de 19" com no mínimo 42 Us.
O que o fornecedor forneceu?
Rack Aberto de 19" com no mínimo 42 Us.
O que o cliente realmente desejava?
"rack fechado de 19" de no mínimo 42us com 570 mm de profundidade. Ou seja, os racks abertos não possuem "profundidade", logo, não será possível a alocação dos servidores de 570 mm de comprimento.
Resultado:
Um projeto prestes a entrar em freezing pois todos os racks foram adquiridos e a metade deles já instalados. Uma solicitação de mudança impacta em custos, prazos e nas demais demandas concorrentes, ou seja, deverá ser (caso a solicitação de mudança seja aprovada) iniciado o projeto "Troca de Racks" para que o projeto atual possa ser continuado.
Debate:
Quem errou nesta?
A-) O cliente.Afinal de contas ele deveria especificar melhor o rack antes de soltar a licitação. O contratado apenas ofertou aquilo que estava no edital.
B-) O contratado. Afinal ele deveria perguntar ao cliente se aquela especificação realmente bastaria
C-) O cliente e o contratado. O cliente deveria especificar melhor e a pré vendas do contratado deveria ter identificado esta especificação incompleta e se fosse o caso alertado
D-)O contratado. Pois está claro que ele se utilizou de uma especificação mal feita para tomar vantagens ofertando racks de menor custo.
F -) NDA.
G-) Todas as questões
....
Complicado....
"O rack deve ser de 19" com no minimo 42 Us, onde 6us devem ser destinadas à instalação de servidores. Servidores estes que serão instalados pela equipe de TI da contratante."
O que a pré vendas inseriu no projeto para aquisições?
Rack Aberto de 19" com no mínimo 42 Us.
O que o fornecedor forneceu?
Rack Aberto de 19" com no mínimo 42 Us.
O que o cliente realmente desejava?
"rack fechado de 19" de no mínimo 42us com 570 mm de profundidade. Ou seja, os racks abertos não possuem "profundidade", logo, não será possível a alocação dos servidores de 570 mm de comprimento.
Resultado:
Um projeto prestes a entrar em freezing pois todos os racks foram adquiridos e a metade deles já instalados. Uma solicitação de mudança impacta em custos, prazos e nas demais demandas concorrentes, ou seja, deverá ser (caso a solicitação de mudança seja aprovada) iniciado o projeto "Troca de Racks" para que o projeto atual possa ser continuado.
Debate:
Quem errou nesta?
A-) O cliente.Afinal de contas ele deveria especificar melhor o rack antes de soltar a licitação. O contratado apenas ofertou aquilo que estava no edital.
B-) O contratado. Afinal ele deveria perguntar ao cliente se aquela especificação realmente bastaria
C-) O cliente e o contratado. O cliente deveria especificar melhor e a pré vendas do contratado deveria ter identificado esta especificação incompleta e se fosse o caso alertado
D-)O contratado. Pois está claro que ele se utilizou de uma especificação mal feita para tomar vantagens ofertando racks de menor custo.
F -) NDA.
G-) Todas as questões
....
Complicado....
André Cruz, PMP
andre_telecom105@hotmail.com
andre_telecom105@hotmail.com
Chat 
MSN: andre_telecom105@hotmail.com
MSN: andre_telecom105@hotmail.comContacte-me 
--- @ WiseStamp Signature. Get it now
Estive sumido...
Olá,
Estive sumido por estes dias (e coloca dias nisso!).
Talvez por conta do projeto citado aqui anteriormente e pelos outros 4 que estavam sob a minha gestão.Enfim neste post quero citar uma passagem que eu ouvi em uma palestra do ótimo Paulo Sabbag (Doutor em Administração pela FGV-EAESP. Engenheiro e Mestre pela Escola Politécnica da USP. Certificado em 1998 pelo Project Management Institute como PMP. É presidente do Conselho de Orientação do Chapter Brasil, SP do Project Management Institute. Leciona no Departamento de Produção e Operações da EAESP/FGV desde 1988, dirigiu o GVpec - Programa de Educação Continuada de 1995 a 1999. Dirige a Sabbag Consultoria desde 1993.)
O tema era sobre as formas de se escolher um gerente de projetos para um projeto. Dentre as técnicas,vamos chamar assim, estavam conhecimento técnico, perfil adequado ao projeto e o último e mais temerário: A disponibilidade do GP.
Ou seja, ainda se escolhem GPs daquele "pool" que está sem projetos ou com projetos menores ou grandes projetos próximos do término.
Para alguns pode até não ser muito desafiador escolher um GP para um projeto. Mas pensemos, uma escolha mal feita pode "queimar " um bom GP em começo de carreira, sobrecarregar o excelente GP (E toda organização tem um deste - Solteiro, sem filhos e sem vida social, afinal de contas, este muitas vezes costuma ter mais de 1 projeto e todos de nível estratégico alto) e é claro, pode também levar um projeto ao fracasso.
Isto também me remete aos escritórios de projeto ou áreas de implantação que não incentivam a paridade de "skills" do time. Você tem de todos os gostos : Bons GPs, Médios, Regulares e até os péssimos.
Este acaba sendo um cenário péssimo para projetos, pois sobrecarrega, desmotiva e não oferece possibilidades de aprendizado muito amplas, enfim, o "turn-over' de empresas como está é elevadíssimo.
Então, pensem na escolha correta!
Estive sumido por estes dias (e coloca dias nisso!).
Talvez por conta do projeto citado aqui anteriormente e pelos outros 4 que estavam sob a minha gestão.Enfim neste post quero citar uma passagem que eu ouvi em uma palestra do ótimo Paulo Sabbag (Doutor em Administração pela FGV-EAESP. Engenheiro e Mestre pela Escola Politécnica da USP. Certificado em 1998 pelo Project Management Institute como PMP. É presidente do Conselho de Orientação do Chapter Brasil, SP do Project Management Institute. Leciona no Departamento de Produção e Operações da EAESP/FGV desde 1988, dirigiu o GVpec - Programa de Educação Continuada de 1995 a 1999. Dirige a Sabbag Consultoria desde 1993.)
O tema era sobre as formas de se escolher um gerente de projetos para um projeto. Dentre as técnicas,vamos chamar assim, estavam conhecimento técnico, perfil adequado ao projeto e o último e mais temerário: A disponibilidade do GP.
Ou seja, ainda se escolhem GPs daquele "pool" que está sem projetos ou com projetos menores ou grandes projetos próximos do término.
Para alguns pode até não ser muito desafiador escolher um GP para um projeto. Mas pensemos, uma escolha mal feita pode "queimar " um bom GP em começo de carreira, sobrecarregar o excelente GP (E toda organização tem um deste - Solteiro, sem filhos e sem vida social, afinal de contas, este muitas vezes costuma ter mais de 1 projeto e todos de nível estratégico alto) e é claro, pode também levar um projeto ao fracasso.
Isto também me remete aos escritórios de projeto ou áreas de implantação que não incentivam a paridade de "skills" do time. Você tem de todos os gostos : Bons GPs, Médios, Regulares e até os péssimos.
Este acaba sendo um cenário péssimo para projetos, pois sobrecarrega, desmotiva e não oferece possibilidades de aprendizado muito amplas, enfim, o "turn-over' de empresas como está é elevadíssimo.
Então, pensem na escolha correta!
quarta-feira, 19 de agosto de 2009
Drama
Sou o Gerente de Projeto de uma implantação de serviços VoIP em um órgão do governo. Projetos que são vencidos em licitação já começam com a maior restrição de todas: PRAZO.
Ainda mais em órgãos do governo onde a licitação já prevê multa por atraso na entrega, e esse acreditem, tem uma bela multa.
Este é o meu drama. Se assumirmos como "T-0" a assinatura do contrato pelo cliente e os prazos da licitação por conta da burocracia no processo de aquisição (Alheio ao gerenciamento de projetos na estrutura da organização executora), o contrato foi adjudicado já com quase 3 meses de atraso. Hoje tenho um escopo gigantesco e menos da metade do prazo para conclusão.
Lição Aprendida: Se o projeto tivesse visibilidade de toda a empresa (Como empresas puramente projetizadas, onde isso passaria por exemplo pela análise de portfólio), os prazos seriam alinhados em toda a cadeia.
Mas como em todo o projeto: O gerente do projeto é o responsável pelo sucesso ou fracasso do projeto.
Oremos.
Gerência de tempo...
Bom, pela data do último post eu ando devendo no quesito que dá o título deste.
terça-feira, 9 de junho de 2009
O dizer não Parte II
Reunião para discussão de cronograma.
"Você deveria ter inserido datas mai agressivas mesmo que fossem datas que nós não atenderíamos. Depois correríamos atrás."
Você assinaria este cronograma? Eu não.
"Você deveria ter inserido datas mai agressivas mesmo que fossem datas que nós não atenderíamos. Depois correríamos atrás."
Você assinaria este cronograma? Eu não.
segunda-feira, 1 de junho de 2009
O dizer não.
É reconhecida como boa prática de gerenciamento de projetos quando não existe concordância com prazos “Jack Bauer" (24 Horas para salvar o mundo), dizer não á administração. Mas é comum que isso aconteça?
Como este assunto nos remete a questão ética do gerenciamento de projetos, onde segundo o PMBOK deve-se sempre "Falar a Verdade" e não sair por aí divulgando cronogramas incoerentes com o pensamento: "Na execução negociamos o atraso" como fazem os maus gerentes de projeto. Porém, e devido a nossa cultura, muitos possam concordar que quando este conceito não está internalizado na cultura da empresa isso se torna uma situação das mais difíceis.
Não raro, em algumas situações até dentro da onde trabalho se ouvir conversas do tipo: Temos que cumprir o prazo para podermos ganhar esta conta. Até concordo que quando existe a real necessidade e o projeto representa um ganho estratégico dentro da organização todo o esforço é válido, mas válido para se atingir o objetivo do projeto acima de tudo, e este objetivo tem que ser tangível, em minha opinião, não é errado dizer á um cliente "Este prazo aumentará os caminhos críticos como consequência, também os riscos do projeto, com base em nossas estimativas, a maior chance de sucesso será cumprir o projeto em "x" dias." Com isso pode-se se estabelecer uma relação de confiança com o cliente.
Porém, ainda acho que com a atual cultura das empresas, atrás de lucros e mais lucros, o "dizer não", ou "não desse jeito" ainda é uma tarefa difícil, mas tem que ser feita.
Como este assunto nos remete a questão ética do gerenciamento de projetos, onde segundo o PMBOK deve-se sempre "Falar a Verdade" e não sair por aí divulgando cronogramas incoerentes com o pensamento: "Na execução negociamos o atraso" como fazem os maus gerentes de projeto. Porém, e devido a nossa cultura, muitos possam concordar que quando este conceito não está internalizado na cultura da empresa isso se torna uma situação das mais difíceis.
Não raro, em algumas situações até dentro da onde trabalho se ouvir conversas do tipo: Temos que cumprir o prazo para podermos ganhar esta conta. Até concordo que quando existe a real necessidade e o projeto representa um ganho estratégico dentro da organização todo o esforço é válido, mas válido para se atingir o objetivo do projeto acima de tudo, e este objetivo tem que ser tangível, em minha opinião, não é errado dizer á um cliente "Este prazo aumentará os caminhos críticos como consequência, também os riscos do projeto, com base em nossas estimativas, a maior chance de sucesso será cumprir o projeto em "x" dias." Com isso pode-se se estabelecer uma relação de confiança com o cliente.
Porém, ainda acho que com a atual cultura das empresas, atrás de lucros e mais lucros, o "dizer não", ou "não desse jeito" ainda é uma tarefa difícil, mas tem que ser feita.
Gerência de Projetos em Telecom
Blog criado para troca de experiências e artigos sobre gerenciamento de projetos aplicados ao setor de telecomunicações.
Assinar:
Postagens (Atom)
