Tag Archives: MPOG

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!

Anúncios

Nova IN 4 – Ordem no Caos?

4 Jan

Muito se sabe das dificuldades e dos meandros das contrações, especialmente de serviços, na administração pública brasileira. Por ter me formado profissionalmente em Brasília e, inevitavelmente, ter prestado serviços para alguns órgãos públicos instalados na cidade, vou tecer breves impressões sobre a IN 4 (instrução normativa 4), lançada em 2008 pela SECRETARIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO do Ministério do Planejamento e que foi atualizada no mês de novembro 2010.

No último congresso de gerenciamento de projetos PMI-DF, realizado em Brasília no mês de outubro, tive a oportunidade de assistir a uma palestra sobre as dificuldades e os riscos de contratação de serviços de TI no serviço público. O nome da palestra (só para deixar registrado) foi: “Altos Riscos na contratação e Gerenciamento de Projetos na Área Pública e abordagem para respectiva mitigação” por Paulo Keglevich de Buzin. Antes de tudo já exponho que a palestra foi muito significativa, principalmente pelo simples fato do tema ser abordado sob a perspectiva do consultor, ou seja, de quem é contratado.

Mas o que quero mostrar é exatamente as contradições e os interesses envolvidos em cada um dos lados envolvidos nessa história: o contratante (administração pública) e o contratado (empresas prestadoras de serviço de TI). Em um tempo não muito remoto, em que, inclusive, eu trabalhei diretamente, muito se via os contratos por Hora Homem, no formato de outsourcing.

Basicamente era assim: o órgão contratava um serviço que não se sabia muito pra que era, e o contratado realizava o trabalho conforme era demandado. Se a empresa tivesse 100 pessoas alocadas em um núcleo de algum órgão, e conforme o perfil destas pessoas, ao final do mês se emitia uma fatura contabilizada por valor Hora Homem (HH) para pagamento. Pois bem: ter medidas de qualidade, produtividade, trabalhos realizados conforme escopo/metas/objetivos e riscos era algo que nem se passava na cabeça. Ou seja, por eu ter profissionais alocados para o “projeto” eu simplesmente recebia valores. Mesmo que 99 dos 100 profissionais alocados nada fizessem durante todo o mês. Absurdo? Talvez.

(É bom lembrar que a gestão destes projetos era muito eficiente pelo lado da contratada!)

Enfim, neste modelo de contratação e gestão de projetos o caos estava instalado. Aí vem a IN 4, que vem a  normatizar  muito do que já está na lei de licitações (8.666). Para que um órgão contrate serviços de TI, caso seja algo comum, ou seja, bens e serviços comuns de TI, obrigatoriamente, deve-se realizar a licitação pela modalidade Pregão. Isso implica em redução de preços. Conseqüência: a administração pública passa a comprar com valores menores. Mas isso realmente traz consigo os melhores serviços ou produtos? Bom, essa é outra questão que deve ser analisada com bastante calma e eu deixarei para outro momento.

Por enquanto, vou focar na IN 4. Então, já sabemos que se for para serviços e produtos comuns, a modalidade deve ser Pregão. Mas o problema central, estava no montante gasto agregado à grandes disperdícios. A IN 4 nada mais fez que o óbvio. É uma tentativa do governo federal em colocar ordem no caos. Primeiramente, ela está voltada para o caos interno. Ela apresenta conceitos e definições importantes, além de fases do processo de contratação que envolve: planejar, monitorar e controlar e aceitar. Além disso, ela dá a oportunidade do departamento de TI de se aproximar das demais áreas de negócio. A IN4 estabelece algo que eu considero fundamental: o estabelecimento de um comitê executivo de TI. Bingo! Esse é o grande negócio. Não se pode achar que a TI deve entender de tudo e contratar da forma que ela quiser. Não! O comitê vai indicar a forma de fazer isso.

Outro aspecto importante da instrução normativa encontra-se no detalhamento das fases. Nela está indicada a responsabilidade de cada um dos personagens envolvidos no processo de contratação. E isso envolve, necessariamente, o departamento que demanda a contratação, a TI que formata essa necessidade, a contabilidade ou outro órgão similar que diz se tem orçamento e uma equipe de gerência do projeto que acompanha e fiscaliza a execução e a entrega dos trabalhos. Outro passo importante é que os departamentos de TI passaram a ser gerenciados exclusivamente por funcionários de carreira e, mais do que isso, a gestão não pode ser objeto de terceirização.

Bom, e o outro lado, o do contratado? A coisa se complicou.  Lembro que a IN 4 foi adotada a partir de uma perspectiva interna. Diante disso, consultores e empresas do setor terão que se adequar à nova realidade. É possível fazer muito com pouco? Eu vejo que sim. Antes a realidade era de caos absoluto. Hoje é de tentar por ordem neste caos. Para o profissional sério e competente a situação de hoje é bem melhor. Acredito que se a IN4 e sua atualização for bem seguida, as empresas prestadoras de serviço poderão encontrar nos órgãos equipes entrosadas e mais qualificadas, além de uma gestão mais eficiente do processo (espera-se). Com isso, não se trabalhará no escuro. E isso é ótimo para todos!

 

 

IN 4: IN4 – 2008-Contratação de Serviços

Boa semana a todos e até a próxima!!!

imagem tirada da internet – Google Images
%d bloggers like this: