Até onde um processo pode emperrar a entrega de um projeto? Uma análise de um caso real.

Publicado a: 17 Agosto, 2015

Categoria: Gestão

Visualizações: 985

Tags: , , ,

No meu último artigo falei sobre “TI como fim ou como meio”, e depois de escrevê-lo comecei uma nova reflexão de como ferramentas e processos poderiam estar prejudicando ou dificultando as entregas de algum projeto ou resultado.

A tecnologia foi feita para automatizar os processos e também para acelerar entregas de um projeto, mas em alguns momentos pode acabar dificultando. Mas não quero rediscutir isso neste momento e quero me voltar mais para as pessoas envolvidas em um projeto e suas entregas.

Lendo o artigo que discute se as empresas estão realmente voltadas ao cliente, comecei a relacionar esta orientação com a TI e as entregas dos projetos. Realmente temos vivido um momento de mudança, de transformação, onde o atendimento das necessidades de nossos clientes tem sido algo primordial. Vemos isso em várias literaturas e pesquisas que mostram que clientes que se encantaram com a entrega de suas necessidades em um projeto tendem a recomprar daquele fornecedor.

Vou ilustrar essa situação e discuti-la com um fato ocorrido.

1. Processo dificultando a entrega

Atuei em um grande projeto para um cliente que era constituído da automação e controle de diversos processos de uma determinada área. O projeto foi longo e várias entregas foram realizadas dentro do prazo e custo estimado. Este stakeholder ficou extremamente satisfeito com a realização das entregas e com as novas possibilidades que teria dalí para frente. Isso fez com que ele iniciasse um grande volume de solicitações. Além disso este stakeholder se tornou um grande influenciador levando as demais áreas a também avaliar as possibilidades daquele projeto.

Em um dado momento, este stakeholder acabou consumindo boa parte do tempo do processo e do orçamento, gerando alguns desgastes com a área de TI. Independente disto, várias entregas foram realizadas, mas algumas delas, muito importantes, que correspondiam a 1% do custo total, foram barradas pela TI, pois não haveria orçamento para as mesmas. Essas entregas bloqueadas já haviam sido desenvolvidas pelo fornecedor e o esforço para desfazer era maior do que o orçamento reservado.

2. E agora, como tratar a situação?

Diante do ocorrido, refleti muito sobre a situação. Concordo que o orçamento deve ser mantido e o processo deve ser seguido, mas até que ponto deve-se ter isso com tanto rigor e rigidez? Não estou dizendo que os processos devem ser burlados ou que devemos achar brechas para fugir do mesmo. Quero propor aqui uma análise de custo benefício, não financeiro, mas sim de satisfação do cliente e o quanto isso poderá trazer de envolvimento do mesmo.

Para o caso citado, foi dada a opção de remanejar o faturamento daqueles itens para outros momentos onde o orçamento comportaria, mas ainda assim a opção foi rejeitada. Ou seja, aquela situação parecia uma punição ao cliente demandante para que o mesmo seguisse o rigor do processo e a demandar com o crivo da TI.

Vendo aquela postura, pensei se aquela era a melhor maneira de tratar a situação, pois aquilo poderia minar a ânsia de evolução e melhoria daquele cliente que agora era influenciador. Será que devemos realmente ser tão rígidos em nossos processos a ponto de impedir uma entrega que cative o cliente? Sempre acredito em saídas criativas, legais e éticas, sem prejuízo ao processo. Mas sempre vale a reflexão de como estamos tratando isso.

Eu consegui resolver a situação. E você, como sairia disso?

Leonardo Carvalho
Gerente de Projetos Senior na Stoque Global Services
LinkedIn | Leonardo CarvalhoTwitter | Leonardo CarvalhoBiografia Completa
Leia mais artigos deste autor.

 

Partilhe este artigo:
Share on Facebook
Facebook
0Share on LinkedIn
Linkedin
Share on Google+
Google+
0Tweet about this on Twitter
Twitter

2 Responses to Até onde um processo pode emperrar a entrega de um projeto? Uma análise de um caso real.

  1. Wladimr diz:

    Em alguns casos (projetos pequenos) algumas etapas do processo de desenvolvimento podem não ser executadas. Nem todos os documentos da metodologia devem ser gerados. Isso pode gerar velocidade e redução de custo no desenvolvimento do projeto.

  2. Roberto Andrade diz:

    As metodologias ágeis pregam a evolução passo-a-passo do projeto, sem o rigor de um cronograma fixo e sempre valorizando o impacto das entregas parciais no benefício para o cliente. Vejo o caso real usado como exemplo um sinal de rigor metodológico que já deveria estar ultrapassado. Típico de uma época em que a TI vivia enclausurada numa redoma de vidro e distante do seu cliente final.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *